Bug 1115053 - Users and Groups admin applet can't be accessed from a normal unpriviledged user.
Summary: Users and Groups admin applet can't be accessed from a normal unpriviledged u...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-users
Version: 22
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1232016 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-01 13:21 UTC by Martin Gregorie
Modified: 2015-06-30 20:20 UTC (History)
7 users (show)

Fixed In Version: system-config-users-1.3.7-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-25 08:25:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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]
[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.


Note You need to log in before you can comment on or make changes to this bug.