New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requests by root over private socket shouldn't cause polkit checks #2748

Closed
grawity opened this Issue Feb 26, 2016 · 11 comments

Comments

7 participants
@grawity
Contributor

grawity commented Feb 26, 2016

systemd version the issue has been seen with

225-1ubuntu9 on Ubuntu (from IRC report); also whatever RHEL7 has (another IRC report); also 229+git on Arch (verified on my system).

In case of bug report: Expected behaviour you didn't see

sudo systemctl <action> should perform the task immediately when invoked by root. (Other than SELinux checks, of course.)

In case of bug report: Unexpected behaviour you saw

Even for UID 0, sudo systemctl <action> still tries to verify the user's access via polkit, and if polkit fails to start systemd cannot be controlled in any useful way, resulting only in error messages written by Xzibit:

<[diablo]> Error getting authority: Error initializing authority: Error sending credentials: Error sending message: Broken pipe (g-io-error-quark, 44)

Also:

<Faux> % sudo systemctl restart redis-server
<Faux> Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24)
<Faux> Failed to restart redis-server.service: Connection timed out

In case of bug report: Steps to reproduce the problem

<Faux> I get it if I restart dbus after some types of upgrades; polkit fails to get back on the bus, and literally everything is totally screwed; can't stop or start services, can't systemctl status, can't reboot.

@FauxFaux

This comment has been minimized.

FauxFaux commented Feb 26, 2016

I (same Faux) also get the slightly varied error message:

% sudo systemctl restart redis-server
Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.PolicyKit1': timed out (g-dbus-error-quark, 20)

I can reproduce it today (but believe I can't normally) by simply systemctl restart dbus.service.

gdb bt of hung systemctl:

(gdb) bt
#0  0x00007f7fc03048fd in __GI_ppoll (fds=0x7ffe48bdd160, nfds=1, timeout=<optimised out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:51
#1  0x0000560875bb625e in ppoll () at /usr/include/x86_64-linux-gnu/bits/poll2.h:71
#2  bus_poll.lto_priv.189 (bus=0x5608777a8010, need_more=<optimised out>, timeout_usec=<optimised out>) at ../src/libsystemd/sd-bus/sd-bus.c:2852
#3  0x0000560875ba402a in bus_process_wait (bus=0x5608777a8010) at ../src/shared/bus-util.c:1701
#4  bus_wait_for_jobs (quiet=false, d=0x5608777a8900) at ../src/shared/bus-util.c:1833
#5  start_unit.lto_priv.351 (bus=0x5608777a8010, args=<optimised out>) at ../src/systemctl/systemctl.c:2745
#6  0x0000560875b9c787 in systemctl_main (bus_error=0, argv=0x7ffe48bdd498, argc=<optimised out>, bus=0x5608777a8010) at ../src/systemctl/systemctl.c:7313
#7  main (argc=<optimised out>, argv=0x7ffe48bdd498) at ../src/systemctl/systemctl.c:7569

@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

I stumbled over this in a different context yesterday: https://lists.freedesktop.org/archives/systemd-devel/2016-April/036135.html . Apparently this is a bug, not a feature, i. e. systemctl is meant to not invoke polkit when running as root.

@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

This can be demonstrated with:

# systemctl stop polkitd
# systemctl status polkitd
● polkitd.service - Authenticate and Authorize Users to Run Privileged Tasks
   Loaded: loaded (/lib/systemd/system/polkitd.service; static; vendor preset: enabled)
   Active: inactive (dead)

### with --no-ask-password polkit does not get activated:
# systemctl enable --no-ask-password systemd-udevd
# systemctl status polkitd
● polkitd.service - Authenticate and Authorize Users to Run Privileged Tasks
   Loaded: loaded (/lib/systemd/system/polkitd.service; static; vendor preset: enabled)
   Active: inactive (dead)

### by default, polkit does get activated:
# systemctl enable systemd-udevd
# systemctl status polkitd
● polkitd.service - Authenticate and Authorize Users to Run Privileged Tasks
   Loaded: loaded (/lib/systemd/system/polkitd.service; static; vendor preset: enabled)
   Active: active (running) since Tue 2016-04-05 08:06:44 UTC; 1s ago
@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

This is apparently a bug in systemctl itself, not in the D-Bus server side (i. e. pid1). If I do

busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss systemd-udevd.service replace

(same with StopUnit) as root, then polkit does not get activated, while it does get activated when calling busctl as user. But the equivalent systemctl start systemd-udevd.service activates polkit. This is also consistent with systemctl itself printing those errors about "polkit not available blabla", not pid 1.

1 similar comment
@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

This is apparently a bug in systemctl itself, not in the D-Bus server side (i. e. pid1). If I do

busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss systemd-udevd.service replace

(same with StopUnit) as root, then polkit does not get activated, while it does get activated when calling busctl as user. But the equivalent systemctl start systemd-udevd.service activates polkit. This is also consistent with systemctl itself printing those errors about "polkit not available blabla", not pid 1.

martinpitt added a commit to martinpitt/systemd that referenced this issue Apr 5, 2016

systemctl: don't start polkit agent when running as root
On the server side we already bypass the polkit checks if the caller is root
(see the sd_bus_query_sender_privilege() call in bus_verify_polkit_async()). So
there is no reason to invoke polkit when running systemctl as root.

Fixes systemd#2748
@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

The fix is rather trivial, committed to https://github.com/martinpitt/systemd/commits/systemctl-polkit . I'll send a PR once github is back on its feet.

@poettering

This comment has been minimized.

Member

poettering commented Apr 5, 2016

I think there's some confusion here. The polkit agent we invoke client side is allergic to being called without PK around. That's something to fix in the PK agent really, which is shipped with PK upstream not systemd.

AFAICS systemd (the server side) is correctly bypassing PK when the client is root anyway.

@martinpitt

This comment has been minimized.

Contributor

martinpitt commented Apr 5, 2016

The polkit agent we invoke client side is allergic to being called without PK around. That's something to fix in the PK agent really, which is shipped with PK upstream not systemd.

Why do we need the polkit agent when systemctl runs as root? We already don't start it with ``--no-ask-password, for remote machines, or with --global`?

AFAICS systemd (the server side) is correctly bypassing PK when the client is root anyway.

Yes, I agree.

martinpitt added a commit to martinpitt/systemd that referenced this issue Apr 5, 2016

polkit: don't start polkit agent when running as root
On the server side we already bypass the polkit checks if the caller is root
(see the sd_bus_query_sender_privilege() call in bus_verify_polkit_async()). So
there is no reason to invoke polkit when running
systemctl/machinectl/loginctl/timedatectl as root.

Fixes systemd#2748
@coling

This comment has been minimized.

coling commented Apr 5, 2016

Tiny clarification in commit message perhaps?

s/reason to invoke polkit when running/reason to invoke polkit agent when running/

Werkov pushed a commit to Werkov/systemd that referenced this issue Jun 22, 2017

polkit: don't start polkit agent when running as root
On the server side we already bypass the polkit checks if the caller is root
(see the sd_bus_query_sender_privilege() call in bus_verify_polkit_async()). So
there is no reason to invoke polkit when running
systemctl/machinectl/loginctl/timedatectl as root.

Fixes systemd#2748

(cherry picked from commit 89d0348)

[fbui: fixes bsc#980490]

adamstegman added a commit to onemedical/dcos that referenced this issue Aug 1, 2017

adamstegman added a commit to onemedical/dcos that referenced this issue Aug 1, 2017

adamstegman added a commit to onemedical/dcos that referenced this issue Aug 1, 2017

@aki-k

This comment has been minimized.

aki-k commented Sep 10, 2017

Edit: My problem was with selinux, not systemd. Sorry about that.

Is there a remedy for CentOS 7.3 with systemd 219? polkitd dies and makes running systemctl commands pretty hard. I have to manually start /usr/lib/polkit-1/polkitd. I'm not running Xorg and just using the root account for now. yum doesn't show any newer version for systemd.

polkitd[pid]: Lost the name org.freedesktop.PolicyKit1 - exiting
@liaogx

This comment has been minimized.

liaogx commented Sep 15, 2018

Here is my error code, so how to solve it?
[root@liaogx home]# systemctl status mysql Unit mysql.service could not be found. [root@liaogx home]# systemctl start mysql Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached (g-io-error-quark, 24) Failed to start mysql.service: Connection timed out See system logs and 'systemctl status mysql.service' for details. [root@liaogx home]#

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment