Re: hotplug ownership/permissions

[David Brownell <david-b@pacbell.net>]

> Playing around with hotplug and noticed that it will set the owner of the
> /proc/bus/usb/xxx/yyy device to the locally logged in user. Is this normal
> behavior, or have I done something weird? 

I think you must have done something wierd.  As distributed, the hotplug
code doesn't chown things, and the kernel doesn't have the concept of
only one logged-in user.  That's a kind of workstation/PC policy, albeit one
that doesn't work when people SSH around much.  Doesn't work for server
hardware.  I understand some of the smarts can be gotten at with PAM.


> 1) set ownership/permissions on the device to locally logged in user (but
> this looks like it's already done ;)

... nope, not today!


> 2) split the usb.handmap out into multiple files located in
> /etc/hotplug/usb.maps . the usb.agent will look in all files in the dir.

Could you elaborate on why you want it to do that?  The only (!)
thing I can see that simplifies is updating each application's entries.
But that's just as easily done by a decent SED script, as part of
application install.


> 3) for EVERY match on the device, load the module, or run the associated
> script (located in /etc/hotplug/usb.scripts). 

It should be doing that already (/etc/hotplug/usb not usb.scripts).


> here's the logic behind this: by running every matching map entry's
> module/script, we can guarantee that a single script won't hog the device.
> the usb.agent will set owner/perms AFTER every script has run so that the
> perms are guaranteed.

I'm missing something here.  Suppose two different apps want to
assign the device to two different users?  One's on the console,
another's on a remote X display (or SSH)?


> Or this one:
> 
> - a mass-storage camera is connected.
> - there are 2 map entries:
> /etc/hotplug/usb.maps/mass-storage   (matches storage class)
> /etc/hotplug/usb.maps/gphoto-storage (matches the VID/PID)
> 
> - the mass-storage entry loads the SCSI emulation and other kernel modules
>   necessary for proper operation. (not necessary?)

Not necessary.  MODULE_DEVICE_TABLE(usb,...) in the usb-storage
driver, added to the hotplug scripts, does that automatically.


> - the gphoto entry calls /etc/hotplug/usb.scripts/gphoto-storage that will
>   then mount the camera to /camera0 and set the perms on the mountpoint to 
>   local user (passed via env variable $USER)

That's something that doesn't exist yet for usb-storage hotplugging:  a
policy module that controls how/where the device is mounted, and
with what permissions (your next point).

I think getting a good solution for that problem will shake loose a
lot of other issues, FWIW.


> - the usb.agent sets owner/permissions to the locally logged in user, or
>   root if none.

That'd likely be a FAT mount option:  "uid=..." and "gid=...".
That "mount the new disk" solution needs such intelligence.

(And by the way, that policy should probably live at the "SCSI hotplug"
level, not the "USB hotplug" level, since otherwise the two would end
up fighting with each other.  No SCSI hotplug yet, but there are noises
about it for the 2.5 series as part of much SCSI cleanup.)


> - this allows for a nice expansion of usb capabilities. Apps can know
> right away if a device has been plugged, unplugged, etc... Think about a
> KDE script that notifies the desktop a camera has been plugged in and it
> opens konqueror automatically, or puts an icon on the desktop right away.
> same for GNOME/Nautilus... or whatever!

But this capability already exists, without changing things.  Assuming that
the KDE/Gnome/... setup recorded "THE" user in a conventional place,
then the /etc/hotplug/usb/WHATEVER script can just use that info.


> Here's a quick question now: Is the hotplug architecture serialized? are
> we guaranteed that only 1 device will be processed by hotplug at a time?

Not at this point.  Originally (back in 2.4.0-test) it was serialized at the
level of individual bus subsystems (like USB, PCI/Cardbus) but that led
to some deadlocks in the networking subsystem so Linus removed that
guarantee.

If you have good patches to re-serialize things in userland, that'd be good.
Remembering that there are complications during OS booting... 

- Dave




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel