Bug 1115053

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-usersAssignee: Nils Philippsen <nphilipp>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 22CC: antonio.montagnani, cwickert, kevin, mitr, nonamedotc, nphilipp, pnemade
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Fixed In Version: system-config-users-1.3.7-1.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-06-25 08:25:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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[15039]: kiwi: Error executing command as another
user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/kiwi]

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.

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.

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.

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:
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.