From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Tue, 04 Dec 2001 00:05:26 +0000 Subject: Re: hotplug ownership/permissions Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > 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