Am Son, 25 Jun 2000 schrieben Sie:
> > > Note that Red Hat and probably other distros do with or without a GUI.
> > > See /etc/security/console.perms.
> >
> > The problem with that approach is that an USB device need not be
> > present when you log in.
>
> Device -- or device node? I'm thinking of tools
> that just change device node permissions for
> things in /dev ... "chmod/chown/..." work fine
> without tyring to open device nodes.
Both, the device obviously.
Aside from maintaining thousands of device nodes, you cannot
know in advance what e.g. /dev/sg3 refers to, when USB comes into
the play.
/dev/video0 being the camera peeking into the hall, is different from
that into the bathroom ;-)
> > To handle permissions together with
> > hotplugging a demon must be running. And it needs kernel hooks to
> > work without races.
>
> The last time this came up, I don't recall any
> races being identified. If the device node starts
> with, say, root ownership and permision 0600, and
> some process comes by (say, around login time)
> and chowns it to "oliver", what's the race?
The race is there as soon as a device is removed and another added.
> > In addition you'll likely need to load a driver
> > before you can decide on permissions, e.g. on an ordinary printer
> > everyone may print, but not on the foto quality expensive ink printer.
>
> You don't really need to load a driver into the kernel to decide
> such stuff, if you use "usbdevfs" (not "devfs"!) calls to ask the
> printer to identify itself. A USB utility was recently posted
> to do that with the IEEE-1284 printer IDs, for example.
In this particular example that is practical. In the general case you
are duplicating drivers in user space, which is suboptimal.
> > There is no sense in duplicating devfs+devfsd.
>
> Of course not. You can do it with a much smaller framework
> already! http://linux-usb.sourceforge.net/usb-admin.html
> has more information about how USB device plugin can make
> Linux "do the right thing" (load driver etc) ... all you
> need to do is hook up a shell script to do the fixup that's
> right for your particular system.
Interresting page. Thanks for the pointer.
But these solutions
a) require usbdevfs
b) suffer from the race mentioned above (at a smaller window)
And usbdevfs, in spite of claims to the contrary, is a form of devfs.
>
> Oh -- and that one works for the cases that the 2.4 devfs
> will not solve, such as USB devices which don't have any
> dedicated device nodes on the filesystem. Mice, keyboards,
> and so on (in typical configurations).
You are right. An extension to the devfs+devfsd scheme is needed. IMHO
kmod should load the drivers upon device plugging.
Regards
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
