Description of Problem: Hampton beta 4 (Skipjack beta 2) /dev/console is not owned by the user like other devices in /etc/security/console.perms . This is a problem because by default gPhoto2 is configured to allow non-root usage of the app, but only if /dev/console is owned by the user running gPhoto2 Version-Release number of selected component (if applicable): $ rpm -q pam pam-0.75-31 [crunge@crunge crunge]$ rpm -q gphoto2 gphoto2-2.0-2 How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: $ rpm -q pam pam-0.75-31 $ rpm -q gphoto2 gphoto2-2.0-2 Additional Information: I tried manually adding console and /dev/console to the <console> line in /etc/security/console.perms but that did not work. I had to create a separate entry called <cons>. Everything worked then, but it would be helpful to either change the pam behavior or the default gPhoto2 setup. Interestingly, it appears that /etc/security/console.perms is setup to _revert_ ownership of /dev/console to root, but not to originally grant the ownership to the user (if I understand this file correctly).
This is expected. Ownership of /dev/console should only be changed if you log in using a display manager such as xdm, gdm, or kdm. Which app are you referring to?
I tested this with my camera on a fresh install of the latest stuff, and i could use gtkam perfectly as a user. pam 0.75-32 gphotot 2.0-2
if /dev/console should be owned by the user only if using a display manager, perhaps this bug should be closed and/or reassigned to gphoto2, which by default assumes ownership of /dev/console (in turn assuming the user is using a display manager) fwiw, I wasn't using a display manager--the system is in runlevel 3 and I use startx to bring up X
Please check if gphoto2-2.0-4 (coming soon to Raw Hide) fixes this for you (it should). This appeared to be caused by a slight problem with the logic in the /etc/hotplug/usb/usbcam script, which assumes that the console user for pam_console always owns /dev/console, which is only the case if a display manager is being used. The update changes the logic to look in the console lock file, which contains the name of the user who is logged in on the console.
Not sure about Chris, but I'm still having problems with /dev/console when gtkam is run as non-root: haring (root):~ > ls -la /dev/console crw------- 1 root root 5, 1 Apr 17 21:38 /dev/console This is with gphoto2-2.0-4.
OK, while I'm still seeing /dev/console owned by root, gtkam appears to be working just fine for non-root, as well as gphoto2 commandline stuff, so guess that we are good to go here.