|Summary:||Users and Groups admin applet can't be accessed from a normal unpriviledged user.|
|Product:||[Fedora] Fedora||Reporter:||Martin Gregorie <martin>|
|Component:||system-config-users||Assignee:||Nils Philippsen <nphilipp>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||antonio.montagnani, cwickert, kevin, mitr, nonamedotc, nphilipp, pnemade|
|Fixed In Version:||system-config-users-1.3.7-1.fc21||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-06-25 08:25:52 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Martin Gregorie 2014-07-01 13:21:50 UTC
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: 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.
Comment 1 Kevin Fenzi 2014-07-02 21:25:39 UTC
I can confirm this here as well... I know it used to work, so not sure what changed. Moving over to polkit for comment...
Comment 2 Fedora End Of Life 2015-05-29 12:16:29 UTC
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.
Comment 3 Miloslav Trmač 2015-06-02 20:12:16 UTC
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.
Comment 4 Nils Philippsen 2015-06-03 09:14:40 UTC
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.
Comment 5 Miloslav Trmač 2015-06-03 15:50:52 UTC
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),
Comment 6 Nils Philippsen 2015-06-05 12:35:46 UTC
Thanks for the explanatoin, Mirek!
Comment 7 Nils Philippsen 2015-06-16 15:10:52 UTC
*** Bug 1232016 has been marked as a duplicate of this bug. ***
Comment 8 Fedora Update System 2015-06-17 11:07:19 UTC
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
Comment 9 Fedora Update System 2015-06-17 11:08:35 UTC
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
Comment 10 Fedora Update System 2015-06-17 11:08:42 UTC
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
Comment 11 antonio montagnani 2015-06-17 11:42:13 UTC
installed and I confirm that it is working......
Comment 12 Fedora Update System 2015-06-20 23:56:30 UTC
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).
Comment 13 Fedora Update System 2015-06-25 08:25:52 UTC
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.
Comment 14 Fedora Update System 2015-06-30 20:20:32 UTC
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.