43

I have a strange issue whenever trying to stop/start a daemon as a regular user, it asks to authenticate with the credentials of another regular user - for example:

[bob@server ~]$ systemctl stop some-daemon.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or units.
Authenticating as: alice
Password:

Why is it asking for alice to authenticate when bob is logged in, and how do I fix this?

Jack O'Leary
  • 533
  • 1
  • 4
  • 4
  • What does the service config file look like? – Jenny D Mar 29 '17 at 14:02
  • @JennyD: Where is the file location of the config? – Jack O'Leary Mar 29 '17 at 14:05
  • What you want? You want start own copy service for each user? E.g. start own VNC-daemon for **alice** and own VNC-daemon for **bob**? – Alexander Tolkachev Mar 29 '17 at 15:25
  • @AlexanderT: Each user needs to have their own vncserver, that's how it's designed, so yes - that is more or less it. Bob isn't running a vnc server though, he's running something unrelated, yet when he tries to start it systemctl asks for alice's password... ( shrug ). – Jack O'Leary Mar 29 '17 at 17:47
  • @JackO'Leary, you could try to use `systemd --user` as it [described in this article](https://wiki.archlinux.org/index.php/Systemd/User). Otherwise, you could give sudo for each user for required services. – Alexander Tolkachev Mar 29 '17 at 20:03
  • @AlexanderT: The article you linked looks fairly in depth, so I'm hopeful something will come to light from it. Thank you for the additional information! – Jack O'Leary Mar 30 '17 at 03:47
  • I think what OP is looking for is `sudo apt-get remove libpolkit-agent-1-0`. – viksit Jun 08 '17 at 08:56
  • Maybe this can help understand a bit more. A service can be configured to be run by a specific user (eg: `start-stop-daemon -u alice`). However, if the user is not a `sudoer` it requires authorization. Even if you are logged as a sudoer (eg: bob), the service attempts to run with the configured non-sudoer. As a workaround you can run from the sudoer, with `su `, eg: `sudo su alice service alices-service status` – Efren Mar 05 '19 at 02:31
  • because you wasn't running the command with sudo. – Toir Apr 15 '20 at 11:30
  • For others who follow the error message here: in my case, I was ssh'ing into the linux laptop where I wanted to restart a service and I didn't even realize it was showing a graphical password prompt to my (same) user on that machine, until I happened to open the lid and see it. From my ssh client session, it just looked like it repeatedly failed after a "timeout" waiting to "connect" (which made no sense since I was already connected over ssh and not trying to reconnect) and I got the above error in the logs which didn't make sense either. – combinatorist Oct 29 '22 at 06:06

4 Answers4

20

Your system is using the polkit Authorization Manager and the message is from the file /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy. polkit can be configured in /etc/polkit-1 and /usr/share/polkit-1 directories, more specifically in the rules.d and actions subdirectories. See the Polkit man page for more information.

In short, the call being made is receiving a response to authenticate as an admin ( auth_admin, auth_admin_keep in manpage ).

In CentOS 7, the /etc/polkit-1/rules.d/50-default.rules file specifies an addAdminRule definition that returns users in the wheel group to authenticate as. All users in the wheel group would be presented as users to select when authentication is required. If Alice was the only user in the wheel group, this would automatically present Alice based on the rule.

Assuming Alice was not in the wheel group, this would suggest that there would be some other definitions of addAdminRule in the rules file paths that allow Alice to be presented as an admin to authenticate as when a request returns an AUTH_ADMIN/AUTH_ADMIN_KEEP response.

Javier C II
  • 3
  • 3
Johan Myréen
  • 461
  • 3
  • 6
  • 1
    From the documentation: "polkit allows users to obtain temporary authorization through authenticating either an administrative user or the owner of the session the client belongs to." Maybe this can give a clue to why it is asking for alice's password. – Johan Myréen Mar 29 '17 at 14:35
  • I think you're onto something here, although I'm still completely lost on where to remove the rule or whatever it is of the other user that keeps asking to authenticate. I looked in both of those directories and even did a grep for "alice" and nothing was returned. – Jack O'Leary Mar 29 '17 at 14:37
  • You said earlier that you did a `su - alice` before starting the vnc daemon. I guess that makes alice the "owner of the session the client belongs to". – Johan Myréen Mar 29 '17 at 14:46
  • What doesn't make sense though was that it was only done for one service, which was then stopped and the user logged out. The other service for bob shouldn't have anything to do with alice as it was something completely different — It's very strange ... I wouldn't mind disabling polkit altogether if this is what it's normal behavior is like. – Jack O'Leary Mar 29 '17 at 14:51
  • You can find out who the owner of the session is with the `loginctl` command. This could confirm or disprove my theory that polkit is asking the owner of the session to authenticate. I really can't say _why_ alice is the owner in this case. – Johan Myréen Mar 29 '17 at 18:26
  • The `loginctl` really didn't return much additional information, but at least you gave me a few things to look into more based upon what you've explained - Thank you. – Jack O'Leary Mar 30 '17 at 03:45
15

When managing system services, you need to do it as root not as normal user. This is indicated by $ character at the end of shell prompt.

You can either use sudo command or switch to root (root shell usually indicated by # char).

Khaled
  • 36,533
  • 8
  • 72
  • 99
  • 2
    Even If I'm doing it as root it asks for the normal users authentication. Basically the root user did `su - alice`, then `systemctl` to start their vnc daemon, but now it asks for their authentication for every `systemctl` no matter what it is... – Jack O'Leary Mar 29 '17 at 13:51
  • I got the error message when I typed '/etc/init.d/munge start'. Adding sudo fixed it. Thanks! – fchen Jul 22 '18 at 18:25
5

As already answered, this message comes from the Polkit Authorization Manager which is in simple words a systemd way of controlling who can do what, including managing systemd services.


For OP the right solution is to configure the service to be a user-level systemd service.


But in case of system-level services here is what you should do:

Add a rule for Polkit that would allow your user to manage the service, like this:

cat > /etc/polkit-1/rules.d/10-some-daemon.rules << POLKIT
polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "some-daemon.service" &&
        subject.user == "bob") {
        return polkit.Result.YES;
    }
});
POLKIT

...buuuuuut with systemd v219 in Centos 7, action does not have access to the unit! This has been added in v226... So you would need to allow the user to manage all units, which is most probably not what you should do...


Therefore I suggest you to switch to plain old sudo to allow your users to manage the services, for example:

cat > /etc/sudoers.d/some-daemon << SUDO
bob ALL= NOPASSWD: /bin/systemctl restart some-daemon.service
bob ALL= NOPASSWD: /bin/systemctl stop some-daemon.service
bob ALL= NOPASSWD: /bin/systemctl start some-daemon.service
SUDO

Main sources:
Greg Dubicki
  • 1,239
  • 1
  • 17
  • 33
3

Check /etc/groups and sudoers rule. This can happen if a person added themselves to the wheel group and became root that way.

natermer
  • 31
  • 1