From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Cuyle Fritzinger Date: Fri, 16 Nov 2001 19:45:56 +0000 Subject: Re: hotplug arch. and apps 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 (warning: here comes a brain dump.) On Fri, 16 Nov 2001, Ken Hahn wrote: > What happens when there are two different packages that want the permissions > set different ways? Which one wins? (the one with the last script) this is a problem. two applications can 'want' to handle the device, but only 1 will win. to fix this, hotplug/usb.agent can set a default/standard security policy such that any device plugged in is owned by the local user (for example). then jphoto and gphoto both know what to expect, and what their respective scripts can do without stepping on each other's toe. all matching scripts are run. this way, no one has to 'win' in order for both to work. non-mass storage camera plugged in > hotplug runs usb.agent > usb.agent sets perms/ownership and calls all matching scripts > jphoto script syncs to disk > gphoto script syncs to disk (too!) - the 'load' of setting permissions and doing stuff with the device is taken away from the scripts and put into usb.agent - another plus is: consider the jphoto sync script. usb.agent can pass in a $USER variable, and jphoto can sync it directly to the user's home directory instead of just to /root - if the user doesn't want both scripts called, they remove one. hotplug will set perms/owner, then call all scripts that match the device ID. taking a step back, really, the local user is the one who 'owns' the device. consider a computer lab where someone brings in a camera and plugs it, they should have perms to use it right away. there are cases when someone shouldn't be have ownership/perms on the device (think USB drive that is used to hold system software, perhaps mounted to /opt or /usr/local). there can be 'exceptions' for devices that shouldn't have the ownership/perms set to the local user. how to define these is something i haven't thought about yet. maybe usb.agent references a file that contains USB VID/PID/SerialNumber and if something matches, perms are left as root only... i don't know... :P what if the user logs out and another logs in? they'll either need to replug the device, or something will need to force the hotplug script to run again for a new local login. that's the downside to this kind of policy and something that should be considered further.. > Also, in a related issue, if you are going to do things like launch an > application when a device is added > (http://jphoto.sourceforge.net/?selected=sync) what happens when both gphoto > and jPhoto decide to launch when a device is added? > A centralized userspace library could keep this from occuring. > (not to mention abstract the interface.. I believe that alsa does something > like this). > Also I think it would provide a single point of entry for security worries > (instead of 10 million startup scripts). this would require some mods to the apps though. not MUCH of a problem. how would something like this work? on startup, would the application 'register' itself and a corresponding script? or would it just register itself, with perhaps a user ID and the lib would take care of permissions/ownership? what about the case where we want to mount a mass-storage device that isn't mounted already? or does hotplug use this library in order to 'set up' the device? if it is for use by an application, then does the application 'register' itself with the library? if this is the case, are any hotplug scripts run and when? if the hotplug scripts aren't run until an application 'registers', then what if i plug in a camera and just 'cd /camera0'. it isn't mounted because no application (gphoto) registered and therefore it isn't mounted automatically... i think i'm asking too many detailed questions without knowing what the full idea behind it... has this been discussed on the list? sorry if he questions are a bit much... :P > It seems like there are two problems here: > 1. The driver side (getting modules loaded/firmware loaded) when a device is > added. It sounds like this side has been pretty well hashed out here, and > just needs to be coded completely. the kernel loader and hotplug scripts deal with this nicely. -=Scott > > Hey hotplug developers! My name is Scott Fritzinger, a developer with the > > gPhoto project (www.gphoto.org) > > > > In pushing out our newest version (2.0), we are coming up with ideas as to > > how to make digital cameras truly "plug and play" (when the user plugs in > > the camera, it's ready to use). We have come up with the following > > solution: > > > > Using a hotplug script (/etc/hotplug/usb/camera), we either set the > > ownership of the device (/proc/bus/usb/001/003 for example) to that of the > > locally logged in user in the case of a non-mass-storage camera, or we > > mount the mass-storage camera to /camera0 and set ownership again to the > > locally logged in user. this alleviates all the problems with permissions, > > and make the camera ready to use right away. > > > > the base of this is of course a hotplug script. there is a catch though: > > how does hotplug know which cameras gphoto (or other applications) > > support? we can easily go through and append the ID's to > > /etc/hotplug/usb.handmap|usb.usermap, but what about when gphoto is > > updated with a new camera list? we'd have to go back through find out > > which entries are there, and then add new ones. and removing an ID would > > be a bit tough too. > > > > I've come up with an idea that would make this REALLY easy to do, and it > > is only slightly different than what hotplug currently does. instead of > > just relying on usb.handmap or usb.usermap, why not create a directory > > /etc/hotplug/usb.map/ and place files in there that contain the ID's for > > the supported devices? the hotplug agent can open each file, look for ID's > > and then run the corresponding scripts. > > > > like, you can place all the HID device "lines" in /etc/hotplug/usb.map/hid > > > > in our (gphoto's) case, we can place everything in > > /etc/hotplug/usb.map/camera for all known (still) camera ID's. This will > > be a VERY generic file, not gphoto specific at all, but rather supportive > > of all apps out there. this file will cause the agent to run the > > /etc/hotplug/usb/camera script, which will then mount (usb mass storage) > > or set permissions on the device. > > > > this design allows for other applications that implement user-land drivers > > via libusb to set up proper permissions on the device when it is plugged > > in. > > > > is it possible alter the usb agent to work in this way? the downside would > > be disk hits for each file in /etc/hotplug/usb.map/* (a little slower), > > but the flexibility is that each application can EASILY update the devices > > it supports by just placing a file in there instead of having to search > > through a single file and replace (usb.handmap). > > > > ideas? thoughts? > > > > Thanks for reading! :) > > > > -=Scott > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ 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