Hey Enrico,

Although it looks simple on the surface, your question got at a wonderful,
thought-provoking design decision (at least, it took me several hours to
think of a good answer). The design question is, for a device filesystem
that equivocates about inode information in order to control access to it,
does the equivocation include changing the inode name? At first, I thought
the answer was "yes" so vdev could support presenting different devices
under the same name to different seats. But, after taking some time to
think about the consequences for path resolution, security, and metadata
consistency, I think the correct answer is "no, we should go with your
original proposal of giving each session its own /dev."

Here's why: while it is certainly possible to write a filesystem that
claims that an inode has a different name depending on which process is
asking, doing so would introduce a lot of non-trivial changes to the
filesystem's semantics. Namely, it raises even more difficult design
decisions, such as:
* What happens if /dev/foo appears as /dev/bar to process A, and process A
tries to mknod() /dev/foo? Should this fail as EEXIST (revealing to
process A that the hidden device /dev/foo exists), or should it succeed?
* If creating /dev/foo succeeds for process A, what happens to the "real"
/dev/foo? What should process B see?
* How are different "versions" of /dev/foo (if I went with supporting this)
affected by ACLs? Is there a way to make vdev smart enough that ACLs
*don't* need to specify which /dev/foo they affect?

I could come up with satisfactory answers to these, given enough time, but
it would take a non-trivial amount of re-engineering to implement them.
Regardless of the answers, vdev would definitely be more difficult to use
as a result, since users wouldn't be able to apply their knowledge of POSIX
filesystems to reason about its behavior. A much more elegant solution
would be to give each session its own /dev like you were originally
saying--it would allow users to interact with different devices under the
same name, while also preserving POSIX filesystem semantics.

Thanks for being patient with me and helping me resolve this!
-Jude

On Tue, Dec 30, 2014 at 4:31 PM, Enrico Weigelt, metux IT consult <
enrico.weigelt@???> wrote:

> On 29.12.2014 04:52, Jude Nelson wrote:
> > 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.
>
> <snip>
>
> Sounds great.
>
> But one question left: can it also rename devices that way ?
>
> Suppose all sessions should see "their" devices as the same names,
> even they're actually different devices (eg. multi-seat) - is that
> already possible ?
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>