On Fri, Jun 23, 2000, Frank van Maarseveen <F.vanMaarseveen@inter.NL.net> wrote:
> 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.
I wasn't talking about block devices, but more along the lines of like
/dev/console.
I guess to properly support multiple consoles, you would need multiple
/dev/console files (/dev/console0, etc) so it would probably not be a
problem.
> 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.
Don't see the device? I don't know the usefulness of that.
I do see the appeal to changing device ownerships on the fly for some
devices. Say the scanner right next to the console.
> 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)...
Please read my little white paper on the subject before thinking too
much about this.
> > 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.
If it emerges with incorrect permissions in a non-chroot jail you still
have problems.
The general idea is to always emerge with safe permissions (root.root
0400 or something else) and then have it updated with different
permissions if we know otherwise.
> 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).
It's already there. It doesn't get used for anything short of output for
ls. In that case they are not very useful since they are just numbers
getting printed.
Perhaps it's used for legacy device drivers when a user manually
mknod()'s the device.
> 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.
Lots of stuff has legacy fields. I just don't think they should be used
anymore.
JE
-
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