All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Cuyle Fritzinger <scottf@med.unr.edu>
To: linux-hotplug@vger.kernel.org
Subject: hotplug ownership/permissions
Date: Mon, 03 Dec 2001 20:07:06 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-100741069725050@msgid-missing> (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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

             reply	other threads:[~2001-12-03 20:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-03 20:07 Scott Cuyle Fritzinger [this message]
2001-12-03 23:28 ` hotplug ownership/permissions Scott Cuyle Fritzinger
2001-12-04  0:05 ` David Brownell
2001-12-04  7:33 ` Tim Waugh
2001-12-04 17:51 ` Scott Cuyle Fritzinger
2001-12-04 22:46 ` David Brownell
2001-12-04 22:59 ` Scott Cuyle Fritzinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-100741069725050@msgid-missing \
    --to=scottf@med.unr.edu \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.