Description of problem: gthumb can not import images from my digital camera. This worked in FC4. Version-Release number of selected component (if applicable):gthumb 2.7.5.1 How reproducible: always Steps to Reproduce: 1. Log in as a non-root user 2. Connect digital camera with USB cable Actual results: Nothing happens Expected results: Should pop up a dialog asking if I want to import the images Additional info: On attempting to manually import (File/Import...), it says it failed to claim the USB device because either some other process has it, or it has no permissions. It was possible to import the images from the digital camera when running gthumb as root. This squarely indicates incorrect permissions on the USB device. I'm logging this as a gthumb bug rather than a hot-plug bug because this behavior is not reproducible with other USB devices (e.g. a USB hard-drive or a USB MP3 player).
Created attachment 128368 [details] Dumps of 'gphoto2 --list-files' debug & strace for root vs. user on FC5
Created attachment 128369 [details] Dumps of 'gphoto2 --list-files' debug & strace for root vs. user on FC5
Sorry about the dupe attachment. The auto-magic import can be re-enabled under System->Preferences->Removeable Drives and Media from the GNOME desktop menus. I get the same error about "claiming a usb device" on my FC5 x86_64 system with a Kodak Z760 (USB PTP) camera. Using 'gphoto2 --list-files' I found that camera access fails for normal users, but works for root. It appears to be a permissions issue with /proc/bus/usb/nnn/mmm. See the dumps in the attached tgz archive. I'm not sure how to get the right permissions to come up on these nodes: udev rules? /etc/security/console.perms? What's the right way for an admin user to fix this in the short term?
More info: Despite hald-runner running as root and despite the /usr/libexec/gphoto-set-procperm script spawned by hald-runner is running with EUID=root and UID=root, the `cat /var/run/console/console.lock` within the script returns permission denied (as did a debug ls command in the script). And % ls -al /var/run/console/console.lock yields -rw------- 1 root andy 4 Apr 28 13:24 /var/run/console/console.lock So I figure SELinux configuration is the culprit. Both /etc/selinux/targeted/contexts/files/file_contexts and /etc/selinux/targeted/modules/active/file_contexts contain a line like: /var/run/console(/.*)? system_u:object_r:pam_var_console_t:s0 And /var/log/audit/audit.log contains: type=AVC msg=audit(1146264308.039:762): avc: denied { search } for pid=7301 comm="cat" name="console" dev=dm-0 ino=14713195 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:pam_var_console_t:s0 tclass=dir type=SYSCALL msg=audit(1146264308.039:762): arch=c000003e syscall=2 success=no exit=-13 a0=7fffffb2e897 a1=0 a2=2 a3=2 items=1 pid=7301 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="cat" exe="/bin/cat" type=CWD msg=audit(1146264308.039:762): cwd="/usr/libexec" type=PATH msg=audit(1146264308.039:762): item=0 name="/var/run/console/console.lock" flags=101 So what's the right way to add /var/run/console/console.lock to the system_u:system_r:hald_t:s0 context?
*** This bug has been marked as a duplicate of 186131 ***