On 26.12.2014 10:01, Jude Nelson wrote:

> We shouldn't have to go this far for device access control. If you
> have a script or program that can print a session's PIDs to stdout,
> you can define vdev ACL rules that will cause vdev to use this
> program to filter device nodes on a per-session basis.

My idea was running each session in an own (partial) container,
which has its own /dev instance, and always use the same filenames
for the devices assigned to that session, whichever that might be
in the actual case. So, for example, /dev/audio would be the audio
device for *this* session. So, we dont need per-session application
configuration for such stuff. (Just have a look on how Plan9
handles that)

Could you explain, how vdev ACLs exactly work ?

Maybe just let's play through certain scenarios.

>> Yes, triggering a config reload is the first necessary step.
>> But I can also imagine an 9P-based interface (synthentic filesystem,
>> just like /proc or /sys) for directly manipulating several settings.
>> Not sure, whether that's really necessary, but we IMHO should keep that
>> in mind.
>
> Ah, I see what you mean. Since vdev is already implemented as a
> filesystem, I'll just have it expose its configuration state as a set of
> read/write files under a well-known directory.

Yeah, that seem the right approach.
OTOH, we should have an option to mount that separately, so containers
can be setup in a way that vdev is running outside the container and
can only be configured from outside.


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287