On Thu, Jun 22, 2000 at 07:30:13PM -0400, Johannes Erdfelt wrote:
> > There are probably a lot of devices which would benefit from a similar
> > access scheme. Every VC login could setup a (partially) inherited
> > capability for that process (inheritance depends on session id?,
> > controlling tty?, uid changes?, login id?). The owner,group and mode of
> > the *devfs files should exactly be conform the effective rights in order
> > to make it all transparent. So, this suggests that the owner of *devfs
> > files could appear to be the uid of the caller when the capability is
> > present and root otherwise, according to stat(), access() and everything
> > else: it is calculated instead of stored.
>
> That would be interesting. Some shared resources could cause problems
> with multiple consoles (multiple keyboards via USB, multiple displays
> via X).
Maybe. I wouldn't want to be automatically the owner of all the block
devices whenever I log in onto a VC. But this must be configurable anyway,
maybe with multiple capabilities and maybe even per VC or only on the
first VC logged in to. There could even be a /etc/capability similar
to /etc/group.
When the owner of a device file is calculated instead of stored it is
possible for different users to have ownership at the same time. So,
physically adjacent hardware can be shared automatically for console
users in a way that has not been possible before. Suppose I want to grab
a device to prevent others from making mistakes. When the mode is 666
and I'm the owner then I could do a chmod 600. The effect could be that
the mode changes and that the owner "freezes", i.e. the other console
users no longer own the device file in their *devfs view or even don't
see the device anymore.
Maybe usbdevfs should list devices by UUID (if it exists) and permit
the owner to rename the thing.
Maybe usbdevfs could remember this all UUID based across remounts.
Now, if someone could only come up with a clean way to preserve UUID
based information for a *devfs (_not_ tar and certainly not built-in in
*devfs itself)...
> I fundamentally disagree with partial views to chroot jails. If someone
> can bypass permissions on the device files, then something else is
> severely broken.
Assuming you have full control over the permissions. That is the case
for a traditional /dev but not necessarily for a *devfs. Newly attached
devices could emerge with incorrect permissions.
By the way, /dev style device files don't have to go away when *devfs has
been perfected. It is probably useful to keep the major/minor numbering
in a *devfs, for compatibility and for informational purposes. It
makes it all more transparent (I haven't tried /devfs yet, maybe it's
already there).
st_dev in a struct stat is never going away I think. That would break
too many programs. I guess major/minor numbers are forever.
-- Frank- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:26 EST