hotplug ownership/permissions

DISCUSSION Scott Cuyle Fritzinger 3 participants 7 messages Dec 3, 2001 – Dec 4, 2001

Share & tools

Scott Cuyle Fritzinger

author

2001-12-03 20:07 UTC #0 lore raw

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Scott Cuyle Fritzinger

author

2001-12-03 23:28 UTC #1 lore raw

Quoted 2 lines · Ken Hahn

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.

Quoted 3 lines

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.

Quoted 1 line

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

David Brownell

2001-12-04 00:05 UTC #2 lore raw

In reply to Scott Cuyle Fritzinger

Quoted 3 lines

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.

Quoted 2 lines

1) set ownership/permissions on the device to locally logged in user (but this looks like it's already done ;)

... nope, not today!

Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 4 lines

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

Quoted 9 lines

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.

Quoted 3 lines

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

Quoted 2 lines

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

Quoted 5 lines

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

Quoted 2 lines

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

Tim Waugh

2001-12-04 07:33 UTC #3 lore raw

In reply to Scott Cuyle Fritzinger

Quoted 8 lines · David Brownell

Quoted 4 lines
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.
*/

Scott Cuyle Fritzinger

author

2001-12-04 17:51 UTC #4 lore raw

In reply to Scott Cuyle Fritzinger

Quoted 6 lines · Tim Waugh

Quoted 5 lines · David Brownell
Quoted 4 lines
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.

Quoted 6 lines

Quoted 3 lines
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

David Brownell

2001-12-04 22:46 UTC #5 lore raw

In reply to Scott Cuyle Fritzinger

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" <[email protected]>
To: "David Brownell" <[email protected]>
Cc: "Scott Cuyle Fritzinger" <[email protected]>; <[email protected]>
Sent: Monday, December 03, 2001 11:33 PM
Subject: Re: hotplug ownership/permissions

Quoted 8 lines · David Brownell

Quoted 4 lines
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.
*/

Scott Cuyle Fritzinger

author

2001-12-04 22:59 UTC #6 lore raw

In reply to Scott Cuyle Fritzinger

Quoted 10 lines · 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!

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

Quoted 9 lines

Quoted 7 lines
Quoted 4 lines
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.