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.weig...@gr13.net> 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
