hotplug ownership/permissions

hotplug ownership/permissions

[Scott Cuyle Fritzinger]

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

Re: hotplug ownership/permissions

[Scott Cuyle Fritzinger]

On Mon, 3 Dec 2001, Ken Hahn wrote:

> 1. The reaction is not serialized as the notificaiton method changes this
> around.

so hotplug needs to selectively choose which script to run based on user
input.

> 2. In the case of a distro where lots of cd-player, or camera-software come
> for free, users could have multiple things launching on an event, instead of
> just one.

then what needs to happen is the user needs to select from a list of
applications which one to launch for a given device, which can be saved in
~/.hotplug or something similar.

how is the user prompted to choose which script? blech. doesn't seem like
hotplug should have knowledge of the desktop itself... perhaps a
/etc/hotplug/usb.delegators/ directory that contains scripts/programs that
will present the user with a list of possible scripts to run, and the user
can specify one or more.. the choices are stored in ~/.hotplug. the
desktops can place the script/programs in /etc/hotplug/usb.delegators/ so
that if there is more than 1 match in usb.maps/, it can run a delegator.
which delegator though? run them all? :P

this is getting nasty.

> Perhaps hogging the device is not a bad idea?

this is tending to lean towards to user preference rather than letting
hotplug delegate which scripts to run.

i can play around and see what works best here and then write back with
results... i'm just trying a bunch of different things to see what works
best for me for now... :P

-=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

Re: hotplug ownership/permissions

[David Brownell]

> 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

Re: hotplug ownership/permissions

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Mon, Dec 03, 2001 at 04:05:26PM -0800, David Brownell wrote:

> > 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)?

I think that for the vast majority of cases, console-user permissions
are desired.

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: hotplug ownership/permissions

[Scott Cuyle Fritzinger]

On Tue, 4 Dec 2001, Tim Waugh wrote:
> On Mon, Dec 03, 2001 at 04:05:26PM -0800, David Brownell wrote:
> > > 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)?
> 
> I think that for the vast majority of cases, console-user permissions
> are desired.

definitely. in the case of system discs (mounted USB discs), you may want
different permissions (root:root), but for most 'personal' peripherals,
you'd want ownership to be that of the console user.

-=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

Re: hotplug ownership/permissions

[David Brownell]

Sure, and I have no problem with applying it in those cases.
I've said so before and have no reason to say otherwise.

But Scott's just described a general mechanism that doesn't
necessarily apply only in that case ... and moreover, said that
the permissions should be set AFTER the scripts that would
be triggering actions that would depend on a particular setting.

Example, some GNOME gPhoto2 GUI starts up and then fails
because it needs a permission setting... because it's set too late!

- Dave


----- Original Message ----- 
From: "Tim Waugh" <twaugh@redhat.com>
To: "David Brownell" <david-b@pacbell.net>
Cc: "Scott Cuyle Fritzinger" <scottf@med.unr.edu>; <linux-hotplug-devel@lists.sourceforge.net>
Sent: Monday, December 03, 2001 11:33 PM
Subject: Re: hotplug ownership/permissions

On Mon, Dec 03, 2001 at 04:05:26PM -0800, David Brownell wrote:

> > 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)?

I think that for the vast majority of cases, console-user permissions
are desired.

Tim.
*/



_______________________________________________
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

Re: hotplug ownership/permissions

[Scott Cuyle Fritzinger]

On Tue, 4 Dec 2001, David Brownell wrote:
> Sure, and I have no problem with applying it in those cases.
> I've said so before and have no reason to say otherwise.
> 
> But Scott's just described a general mechanism that doesn't
> necessarily apply only in that case ... and moreover, said that
> the permissions should be set AFTER the scripts that would
> be triggering actions that would depend on a particular setting.
> 
> Example, some GNOME gPhoto2 GUI starts up and then fails
> because it needs a permission setting... because it's set too late!

a quick clarification that i didn't make in my original post: the
permissions are set after each script (in case there is a script that
'behaves badly') so that the 'next' script is guaranteed the proper
permissions. the usb.agent would just make sure that the state going into
each script is set properly (perm/owner).

-=Scott

> > > 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)?
> I think that for the vast majority of cases, console-user permissions
> are desired.


_______________________________________________
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