On Fri, Jun 23, 2000, Frank van Maarseveen <F.vanMaarseveen@inter.NL.net> wrote:
> 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.
>
> How would you implement managing access rights? The traditional
> way with chown/chmod seems inappropriate when there is no state.
There must be state. The current implemented solution doesn't handle
this.
Basically, if I chmod the file for my digital still camera. I want that
permission to be automatically applied back to the file when I plug it
back in.
This doesn't happen now. Well, I have patches and code to do it, but
it's been deemed too experimental to used now.
> 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.
That would be interesting. Some shared resources could cause problems
with multiple consoles (multiple keyboards via USB, multiple displays
via X).
> 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.
I fundamentally disagree with partial views to chroot jails. If someone
can bypass permissions on the device files, then something else is
severely broken.
However, Richard has apparentely been working on something like this for
devfs. I haven't looked at it yet, but if usbdevfs were rolled into
devfs, then it would have this feature as well.
> 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.
It's definately new territory. I posted a quick draft of my white paper
on Linux and Hot-Swap on the devfs list.
I hope it helps everyone understand the problems that currently exist,
with my stab at solving it for USB specifically.
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:25 EST