Description of problem: Applications Menu|Administration|Users and Groups is no longer accessable from an unpriviledged login. There is no prompt given for the root password and the Users and groups management applet is not displayed. /var/log/secure shows this: Jul 1 14:00:44 zappa pkexec[15039]: kiwi: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/kiwi] [COMMAND=/usr/share/system-config-users/system-config-users.py] Version-Release number of selected component (if applicable): xfce4-panel 4.10.1 How reproducible: I can't NOT reproduce the problem. Steps to Reproduce: 1. Select Applications Menu|Administration|Users and groups Actual results: No root password prompt is shown. Screen continues to show the Administration menu. Expected results: To be prompted for the root Password, to input it and be shown the Users and Groups management screen.
I can confirm this here as well... I know it used to work, so not sure what changed. Moving over to polkit for comment...
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Thanks for your report. For some reason I couldn’t immediately reproduce this on F20, but on F22 it happens reliably. An alternative way to reproduce: > $ ( /usr/bin/system-config-users &) > Refusing to render service to dead parents. system-config-users runs: > exec /usr/bin/pkexec /usr/share/system-config-users/system-config-users.py pkexec needs to authorize the unprivileged process that launched it, but in GNOME (and perhaps xfce started doing this as well?) GUI applications are started through double-forking so that their process is init instead of the session (no idea why, but I digress…) So, the desktop launches /usr/bin/system/config-users, reparenting it to init, and when the process is replaced by pkexec, pkexec refuses to continue when its parent is init instead of an unprivileged process within the user session. Just dropping the “exec” might be sufficient.
Someone please explain me _how_ exec contributes to it, because AIUI exec replaces the current process (pid, owner, permissions, etc.) with a new executable. Also, what is the advantage of double-forking, why is it that init needs to own the processes. I'm asking because "exec ..." is a normal way for shell wrappers to start the actual programs and not keep the wrapper process around unnecessarily, see how e.g. firefox and chrome/chromium are started.
The desktop starts applications through double-forking; GNOME has been doing this for a very long time. As I wrote above I am not certain why this needs to happen; https://git.gnome.org/browse/glib/tree/glib/gspawn.c suggests that reparenting the final child process to init means that the parent does not have to care about reaping the child (calling waitpid etc.), which makes sense (but I haven’t verified that this is the relevant code path). Yes, exec is a normal way to avoid a parent process, but polkit needs a parent process which is different from init, as a subject for the permission check (both init and pkexec itself run as root, so are not suitable as permission check subjects). firefox and chrome/chromium are, unlike pkexec, not setuid and do not need to care about the specific identity of their parent, only about their own identity. pkexec used allow init as a parent, but this got stricter in 2011 as a part of security hardening (commit 3b12cfac),
Thanks for the explanatoin, Mirek!
*** Bug 1232016 has been marked as a duplicate of this bug. ***
system-config-users-1.3.7-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/system-config-users-1.3.7-1.fc22
system-config-users-1.3.7-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/system-config-users-1.3.7-1.fc21
system-config-users-1.3.7-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/system-config-users-1.3.7-1.fc20
installed and I confirm that it is working......
Package system-config-users-1.3.7-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing system-config-users-1.3.7-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10137/system-config-users-1.3.7-1.fc20 then log in and leave karma (feedback).
system-config-users-1.3.7-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
system-config-users-1.3.7-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.