From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Cuyle Fritzinger Date: Mon, 03 Dec 2001 20:07:06 +0000 Subject: hotplug ownership/permissions Message-Id: List-Id: 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? This is one thing I wanted the script to do, but don't know if this has been the behavior all along, or if I did something weird. :P Also, i'm starting to hack around with usb.agent on my machine to do the following: 1) set ownership/permissions on the device to locally logged in user (but this looks like it's already done ;) 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. 3) for EVERY match on the device, load the module, or run the associated script (located in /etc/hotplug/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. Consider this scenario: - a PTP camera is connected. - there are 2 map matching map entries. one in each: /etc/hotplug/usb.maps/jphoto /etc/hotplug/usb.maps/gphoto the least specific matching map entry (class, then vendor/product id) is run first - the jphoto map entry calls the /etc/hotplug/usb.scripts/jphoto to dump all pictures to disk (check David's great hotsync script at jphoto.sourceforge.net) - the gphoto map entry calls /etc/hotplug/usb.scripts/gphoto to maybe do the same, or to signal the desktop that a camera has been plugged in. - the usb.agent sets owner/permissions to the locally logged in user, or root if none. 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?) - 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) - the usb.agent sets owner/permissions to the locally logged in user, or root if none. i know there were mentions of behaving properly with the modules.usbmap file, so the mass-storage map above is probably not necessary as the kernel will load the class driver automatically. so ignore that if it isn't needed :) It has the following benefits: - Multiple applications can do whatever they want (jphoto, gphoto, etc..) if they place a map in /etc/hotplug/usb.maps/ not one application 'hogs' the device. - 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! - local user has perms on the device. no more emails from people about not being able to access their digicams (OK OK, this is mainly for gphoto's benefit ;)... other devices as well though... - !!EASY!! to add and remove map entries. add or remove a file at application installation/removal. no more sed'ing through the usb.{user|hand}map files. 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? What do people think of this? Thanks for listening! -=Scott Fritzinger _______________________________________________ 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