Bug 187971 - Device node for digital camera not owned by console owner
Device node for digital camera not owned by console owner
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-04 19:50 EDT by W. Michael Petullo
Modified: 2013-03-05 22:45 EST (History)
5 users (show)

See Also:
Fixed In Version: 0.5.8.1-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-14 21:49:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description W. Michael Petullo 2006-04-04 19:50:49 EDT
Description of problem:
When I plug in a USB digital camera to a computer running Fedora, I expect the
device node to be owned by the owner of the console.  This is true of scanners.
   Udev creates /dev/scanner... and executes pam_console_apply to set
permissions according to 50-default.perms.  This does not happen when I plug in
my digital camera.

Version-Release number of selected component (if applicable):
pam-0.99.3.0-2
udev-084-13

How reproducible:
Every time

Steps to Reproduce:
Plug in a USB digital camera.
  
Actual results:
/dev/bus/usb/00x/00y is owned by root.

Expected results:
/dev/bus/usb/00x/00y should be owned by the console owner.

Additional info:
The camera is a Canon Digital Ixus.

T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=04 Dev#= 20 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=32 #Cfgs=  1
P:  Vendor=04a9 ProdID=3045 Rev= 0.01
S:  Manufacturer=Canon Inc.
S:  Product=PowerShot S100
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=96ms
Comment 1 Tomas Mraz 2006-04-05 03:15:55 EDT
First the udev has to create some symbolic link (for example camera-...) in /dev
and then it can be added to the /etc/security/console.perms.d.
Comment 2 Harald Hoyer 2006-04-05 05:55:10 EDT
Hmm... should probably be done by HAL.
Comment 3 John (J5) Palmieri 2006-04-17 17:00:41 EDT
This is done in /usr/libexec/gphoto-set-procperm.  se-linux has been a problem
in the past with respect to this.  Do you get any messages in
/var/log/audit/audit.log?
Comment 4 W. Michael Petullo 2006-04-17 21:24:19 EDT
SELinux is not enforcing its policy.  I have SELinux running in permissive
mode.

gThumb says:

An error occurred in the io-library ('Could not claim the USB device'):
Could not claim interface 0 (Operation not permitted). Make sure no other
program or kernel module (such as sdc2xx, stv680, spca50x) is using the
device and you have read/write access to the device.

As I mentioned before, the device remains owned by root.

$ rpm -qf /usr/libexec/gphoto-set-procperm
gphoto2-2.1.99-8
Comment 5 John (J5) Palmieri 2006-04-19 17:08:11 EDT
There is a line in /usr/libexec/gphoto-set-procperm

chown $console_user /dev/bus/usb/$bus_num/$dev_num

This should do the ownership change for you.  Can add this to the script after
the chown line:

echo "chown $console_user /dev/bus/usb/$bus_num/$dev_num" > /tmp/gphoto-perm.debug

Attach /tmp/gphoto-perm.debug to this report. Thanks.
Comment 6 W. Michael Petullo 2006-04-19 21:15:22 EDT
/usr/libexec/gphoto-set-procperm is not run.  Here is a section of lshal's
output for the camera:

udi = '/org/freedesktop/Hal/devices/usb_device_4a9_3045_noserial_if0'
  info.udi = '/org/freedesktop/Hal/devices/usb_device_4a9_3045_noserial_if0' 
(string)
  camera.libgphoto2.support = true  (bool)
  camera.libgphoto2.name = 'Canon PowerShot S100'  (string)
  camera.access_method = 'proprietary'  (string)
  info.capabilities = {'camera'} (string list)
  info.category = 'camera'  (string)

Note that camera.access_method = 'proprietary' even though libgphoto2 is able to
access this camera.  I think this should be = 'libgphoto2.'
Comment 7 W. Michael Petullo 2006-04-19 21:19:19 EDT
In fact, editing the following file:

/usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi

as such for the Canon PowerShot S100 section:

- <merge key="camera.access_method" type="string">proprietary</merge>
+ <merge key="camera.access_method" type="string">libgphoto2</merge>

fixes the problem.
Comment 8 John (J5) Palmieri 2006-04-20 11:25:12 EDT
That file is generated by gphoto2.  The right fix would be for me to key off of
info.capabilities instead of camera.access_method. Thanks for helping me debug this.
Comment 9 W. Michael Petullo 2006-05-29 23:18:25 EDT
Gphoto2 2.1.99-12 from Rawhide does not seem to contain the proposed fix.
Comment 10 W. Michael Petullo 2006-08-19 11:54:34 EDT
John, based on your comment #8, should this be assigned to gphoto2?  The
gphoto2-2.2.0-2.1 package from Rawhide still seems to have this problem.
Comment 11 W. Michael Petullo 2006-11-25 12:39:00 EST
This seems fixed, but I am not clear what was changed.  John or David, could you
confirm that a fix was implemented?  I would like to close this bug, but wish to
confirm that things are fixed and this does not just work because of something I
did locally.
Comment 12 Mike Fleetwood 2007-01-14 16:11:04 EST
I had exactly the same problem on my FC5 box with my Canon PowerShot A40 camera.
 For me the problem has also gone away.  Michael's question in comment #11 about
what changed to fix it made me curious.  What fixed the problem is upgrading
from gphoto2-2.1.99-8 to gphoto2-2.3.1-1.fc5.  In particular this change to
/usr/share/hal/fdi/policy/20thirdparty/90-gphoto-camera-policy.fdi:
-      <match key="camera.access_method" string="libgphoto2">
+      <match key="camera.access_method" string="proprietary">

I guess that this bug can now be closed.

Thanks, Mike
Comment 13 W. Michael Petullo 2007-01-14 21:49:39 EST
Seems fixed.  I will reopen if I have trouble in the future.  Thank you.

Note You need to log in before you can comment on or make changes to this bug.