Re: hotplug arch. and apps

[Scott Cuyle Fritzinger <scottf@med.unr.edu>]

(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