> 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.weigelt@???> 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
>