> > 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.
> 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?
> 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.
> 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.
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).
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
