On Wed, Jun 21, 2000 at 05:50:11PM -0400, Johannes Erdfelt wrote:
> > It is
> > interesting though, but what I saw in /proc/bus/usb was not a replacement
> > for any device file such as /dev/usb/lp0. It only provided for some debug
> > info.
>
> You are correct, it does not replace /dev/usb/lp0. However, it is much
> more than debug info. It's the whole userspace API. libusb uses it to
> communicate to devices. gphoto uses libusb to communicate to digital
> still cameras through it.
> It's the whole userspace API, kinda like the SCSI generic interface. I'd
> like to keep the devices and drivers file in /proc, and move the rest to
> /dev.
>
> JE
How would you implement managing access rights? The traditional
way with chown/chmod seems inappropriate when there is no state.
It could be done using capabilities but I'm not sure where that would
lead to. Maybe it depends on the kind of device whether or not it makes
sense to make access rights dynamic. This reminds me what KDE does with
"consolehelper". This permits a non-root user to do all kind of things
as root, provided the person sits behind the machine (tty must be a
virtual console I believe). After all, in that position one can usually
kick the hardware or do other disturbing things.
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.
usbdevfs is less flexible in another aspect compared to device files: It
is not possible to make a selection of devices available, e.g. in a chroot
jail. Sounds minor to me but it could be important. As long as every
*devfs file still has a major/minor device number counterpart this is not
really an issue.
What is cool about usbdevfs (and devfs'es in general) is the automatic
[dis-]appearence of the necessary device files, keeping it exactly in
sync with the hard- and software. What is cool about /dev is the clean
separation between device numbers (kernel issue) and (path)names to access
them (userland issue) and above all the idea to manage rights to devices
in a similar way as for any other file. Everything is a file.
I find this all an intriguing puzzle.
-- 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:24 EST