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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
