Description of problem: system-config-users will not startup. After the user authentication dialog nothing happens. Version-Release number of selected component (if applicable): 1.2.110-1.fc16 How reproducible: run from 'users & groups' menu or command line. Steps to Reproduce: 1. 2. 3. Actual results: Nothing happens when run from the menu. When run from the command line I get > No protocol specified > system-config-users requires a currently running X server. I am running KDE Expected results: GUI to change users Additional info: Running under KDE.
Please run this command and post the output (or attach it if it's too long to paste), thanks: python -c "import gtk"
Hi Nils, That doesn't produce any output at all !
Odd... Can you start s-c-users like the following from the command line? su -c /usr/share/system-config-users/system-config-users It will ask you for the root password before attempting to start the program.
Yes, that works thanks
If this works, but calling s-c-users normally doesn't then I suspect that this needs to be looked at from the usermode side (i.e. what normally asks for the root password and starts the program with root privileges), to check on what exactly fails in your environment (e.g. passed on environment, stuff necessary for X11 to work). Changing component.
Do you see anything suspicious in /var/log/secure when you try to start the s-c-users normally?
I don't know if it's suspicious, but I'm getting this > userhelper[2299]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'richard' There is a stray space in there at the end of s-c-users, if that's important?
(In reply to comment #7) > There is a stray space in there at the end of s-c-users, if that's important? I believe this is stray space gets added by usermode as I get the same, but s-c-users starts for me.
Can you add debug option to the pam_xauth line in /etc/pam.d/config-util and retry and look into the /var/log/secure if there is something more?
(In reply to comment #7) > I don't know if it's suspicious, but I'm getting this > > > userhelper[2299]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'richard' > > There is a stray space in there at the end of s-c-users, if that's important? That is a bug in usermode, fixed in upstream commit 12654ab332d81c30b1aa390d98d149da2de8abe9 . It is only incorrect in the log entry.
Richard, thanks for your report. I'm afraid I can't reproduce the problem, and I'll need some more information. (In reply to comment #0) > Nothing happens when run from the menu. > When run from the command line I get > > No protocol specified > > system-config-users requires a currently running X server. Do I understand correctly that an authentication dialog appears as well, and that these messages appear only after you successfully authenticate? Does system-config-users work when you do (su -) and then run /usr/bin/system-config-users from the command-line? Does system-config-users work when you do (su -) and then run /usr/share/system-config-users/system-config-users from the command-line? Please run the following commands: > echo $DISPLAY > echo $XAUTHORITY > xauth list > su - -c '(echo $DISPLAY; echo $XAUTHORITY; xauth list)' and paste the output. Also, as root please temporarily add the following lines: > echo $DISPLAY > echo $XAUTHORITY > xauth list after the first line of /usr/share/system-config-users/system-config-users , then run "system-config-users" as an unprivileged user, and paste the output. Finally, as root please make sure the strace package is installed, and temporarily edit the last line of /usr/share/system-config-users/system-config-users to read > strace -ff -s 512 -o /tmp/scu-log /usr/bin/python2 /usr/share/system-config-users/system-config-users.py and run "system-config-users" as an unprivileged user. Then attach all files /tmp/scu-log*, and also /etc/pam.d/system-config-users, /etc/pam.d/config-util, /etc/pam.d/system-auth. I'd be happy to explain any of these steps in more detail if necessary.
Created attachment 677742 [details] scu-log-15971 This is David Hanson's strace debug file for system-config-users
Created attachment 677743 [details] David Hanson's /etc/pam.d/system-config-users This is David Hanson's /etc/pam.d/system-config-users file
Created attachment 677744 [details] David Hanson's config-util
Created attachment 677745 [details] David Hanson's /etc/pam.d/system-auth
Hello. I am having exactly this problem. Here is the information you requested: new-host-2:~> whoami cmartoff new-host-2:~> uname -a Linux new-host-2 2.6.32-279.19.1.el6.x86_64 #1 SMP Tue Dec 18 17:22:54 CST 2012 x86_64 x86_64 x86_64 GNU/Linux new-host-2:~> echo $DISPLAY; echo $XAUTHORITY; xauth list :0.0 /var/run/gdm/auth-for-cmartoff-WF28M0/database localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 e2e7071ed54e5ee6c6373ebf18a2aeab new-host-2:~> su - -c '(echo $DISPLAY; echo $XAUTHORITY; xauth list)' Password: :0.0 xauth: creating new authority file /root/.Xauthority =================================================================== =================================================================== # edited system-config-users as requested new-host-2:~> whoami cmartoff new-host-2:~> system-config-users :0.0 xauth: creating new authority file /root/.Xauthority No protocol specified system-config-users requires a currently running X server. =================================================================== The strace and other files you requested are attached. Thank you.
Richard and David, system-config-users-1.3.3 was just pushed as an update for Fedora 16. This updated version uses pkexec instead of usermode to handle privileged authentication, please check if your problems persists with this version. Thanks!
(In reply to comment #17) > Richard and David, > > system-config-users-1.3.3 was just pushed as an update for Fedora 16. This > updated version uses pkexec instead of usermode to handle privileged > authentication, please check if your problems persists with this version. > Thanks! Hi Nils, I'm running on Fedora 17 these days ,and its working OK, thank you. The only slightly strange thing is the authentication dialog doesn't default to the current user, but that's not a big issue.
Folks- Thanks for the reply... however I am running EL6 (actually Scientific Linux 6.3) $ uname -a Linux E6500.localdomain 2.6.32-279.19.1.el6.i686 #1 SMP Tue Dec 18 17:26:17 CST 2012 i686 i686 i386 GNU/Linux Fedora 16 uses kernel 3.1.0. Will the system-config-users-1.3.3 version work with my kernel? Thanks.
David, thanks for the data. (In reply to comment #16) > new-host-2:~> su - -c '(echo $DISPLAY; echo $XAUTHORITY; xauth list)' > Password: > :0.0 > > xauth: creating new authority file /root/.Xauthority This suggests that this a problem with pam_xauth not forwarding the authorization, probably not specific to userhelper, so reassigning to pam. You may be able to get useful debugging information by adding "debug" to the pam_xauth line in /etc/pam.d/config-util, so that it reads > session optional pam_xauth.so debug
(In reply to comment #18) > I'm running on Fedora 17 these days ,and its working OK, thank you. > The only slightly strange thing is the authentication dialog doesn't default > to the current user, but that's not a big issue. It would ask you for your own password if your user is in the "wheel" group, and for the root password otherwise. That's intentional. (In reply to comment #19) > Thanks for the reply... however I am running EL6 (actually Scientific Linux > 6.3) I don't see me rebasing s-c-users to -1.3.x on RHEL6 soon, so unless SL would update to that version on their own... > Fedora 16 uses kernel 3.1.0. Will the system-config-users-1.3.3 version > work with my kernel? The kernel shouldn't matter much, s-c-users-1.3.x may pull in some updated dependencies which aren't in EL6, so you might have to update these as well. But at your own risk, of course ;-).
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.