> Great. What we now need is a login tool (or PAM module) which puts each > user session into an own namespaces or even container. And we'll need a > meta-config system, which then generates the configs for the individual > instances from a central host configuration. (eg. picking the right > devices that should be given to a particular session).
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. > 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. -Jude On Fri, Dec 26, 2014 at 12:31 AM, Enrico Weigelt, metux IT consult < enrico.weig...@gr13.net> wrote: > On 24.12.2014 06:48, Jude Nelson wrote: > > Hi, > > (bouncing back to the list for a broader discussion) > > > Thanks for your feedback! The "container friendliness" design point > > is intentional, and can certainly be used to give each user/session > > their own /dev instance. > > Great. What we now need is a login tool (or PAM module) which puts each > user session into an own namespaces or even container. And we'll need a > meta-config system, which then generates the configs for the individual > instances from a central host configuration. (eg. picking the right > devices that should be given to a particular session). > > > I haven't added it yet, but it will be possible to signal a vdev > > instance to reload its configuration (i.e. send it SIGUSR1 or similar). > > Is that what you're getting at? If not, can you flesh out your example > > a bit more? > > 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. > > > cu > -- > Enrico Weigelt, > metux IT consulting > +49-151-27565287 >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
