Hi Enrico,

ACLs act as whitelists that additionally let vdev equivocate about device
nodes to different processes, based on the user, group, process information
(PID, inode, binary path, SHA256), and requested device file. Let's work
through a few examples.

Consider the following ACL, which hides both the random and urandom device
nodes from user 'jude':

[vdev-acl]
uid=jude
paths=.*random
setmode=0000

Then, if I run "su jude -c ls /dev", both /dev/random and /dev/urandom will
be missing from the output.

Here's a more practical example that hides /dev/input/* and /dev/dri/* from
every program except the X server (installed to /usr/bin/X):

[vdev-acl]
bin=/usr/bin/X
paths=input/.*|dri/.*
setmode=0666

Now, suppose I had a program called "session-ps", which took a username as
an argument and printed a newline-separated list of PIDs for the processes
belonging to all of that user's login sessions. For example:

$ session-ps jude
28143
30888
32179

Suppose you have a multi-seat environment, and we want to forbid jude from
accessing the device nodes under /dev/usb/001 since they correspond to a
USB hub in a different seat. You can create an ACL to enforce this, such
as this:

[vdev-acl]
pidlist=/usr/bin/session-ps jude
paths=/dev/usb/001/.*
setmode=0000

Then, if user jude runs "ls /dev/usb/001", he will see an empty directory.

You can also define ACLs to present device nodes to different processes as
having different owners and permission bits, depending on who's asking.
For example, suppose you wanted all storage media to be writable to the
fsck program, but you wanted them to appear to fsck to be owned by the
'staff' group. You could have an ACL that does this:

[vdev-acl]
bin=/sbin/fsck
paths=/dev/s[d|r]*.*
setmode=0666
setgid=staff

Intuitively, the way ACLs work is as follows:
1. A request for inode data (stat, access, or readdir) comes in via FUSE.
vdev sees the requesting process's UID, GID, and PID
2. vdev matches the process information, path, and inode information
against its list of ACLs (looking up extra information about the process if
need be)
3a. If an ACL matches, vdev alters the stat buffer for the inode
accordingly and replies it to the requesting process via FUSE.
3b. If no ACL matches, vdev fails the request with ENOENT (or doesn't
reply with the inode information at all).

With ACLs, you can match a request on the following keys:
* uid: username or user ID to match against the requesting process
* gid: group name or ID to match against the requesting process
* bin: path to the requesting process's binary to match against the
requesting process
* pidlist: a program to invoke as a subprocess that prints the list of
PIDs to match against the requesting process's PID
* sha256: the SHA256 hash of the requesting process's binary
* inode: the filesystem inode number of the binary of the requesting
process's binary
* paths: a POSIX regular expression to match the request's path

Before replying an inode's stat buffer, you can have the ACL perform the
following alterations on it first:
* setuid: set the username or user ID in the stat buffer
* setgid: set the group or group ID in the stat buffer
* setmode: set the mode in the stat buffer

You can also have vdev take actions after it creates or removes a device
node, but for your purposes I think that's the subject for a different
email.

Hope this helps,
-Jude

On Fri, Dec 26, 2014 at 8:50 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt@???> wrote:

> 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
>