Admin mode does not work with polkit

[ananthb]

Explain what happens

1. I have Arch Linux with polkit and doas installed.
2. I login to cockpit web and try to enter administrator mode.
3. This fails with an error about sudo.

Version of Cockpit

cockpit 285-1

Where is the problem in Cockpit?

Accounts

Server operating system

Arch Linux

Server operating system version

No response

What browsers are you using?

Firefox, Firefox Mobile on Android, Chrome, Safari macOS

System log

No response

[harsh098]

May I work on this issue

[martinpitt]

@ananthb : Can you please confirm that running pkexec cockpit-bridge --privileged works for you in a shell? In the sense that it actually starts cockpit-bridge after authentication. It will fail with something like "Socket operation on non-socket", but that's fine. How does it look like exactly in Cockpit? Do you get an error message in the dialog? Please post screenshots, journal log, and any other details which might be helpful.

@mvollmer : Something for you to investigate? Running with polkit should work in general, no?

@harsh098 : Sure, feel free to chime in! However, this isn't a very good "first issue for new developers" I'm afraid, it needs a lot of knowledge about how Cockpit works.

[jelly]

Arch Linux does ship /usr/share/polkit-1/actions/org.cockpit-project.cockpit-bridge.policy in it's package so that ought to get triggered.

[jelle@t14s][~/projects/cockpit/codeql-fixes-2]%pkexec cockpit-bridge --privileged
27

{"command": "send-stderr"}cockpit-bridge: recvmsg(stdin) failed: Socket operation on non-socket

[jelle@t14s][~/projects/cockpit/codeql-fixes-2]%sudo cockpit-bridge --privileged
27

{"command": "send-stderr"}cockpit-bridge: recvmsg(stdin) failed: Socket operation on non-socket

[ananthb]

Sorry for the scant details in the initial bug report. I had to wait to uninstall sudo and try it out.

@ananthb : Can you please confirm that running pkexec cockpit-bridge --privileged works for you in a shell?

Yeah I get this error:

{"command": "send-stderr"}cockpit-bridge: recvmsg(stdin) failed: Socket operation on non-socket

Without sudo installed, there's a dialog for admin access:

Clicking it leads to this popup:

I wasn't sure which unit to look at the logs for so I was following the system journal. My user account is created and managed by systemd-homed. Could this be the source of the issue?

[martinpitt]

According to the journal, the polkit agent was successfully registered. The "spawn failed" does not say much detail unfortunately, nor does the journal have any details. homed should not be a problem -- I'm using that as well, unlocking it succeeded, and you did get a Cockpit session as user "ananth".

Notes for our development team:

I reproduced this on Fedora 37, our standard test VMs. Just rpm -e sudo sudo-python-plugin, then I get the same "Spawn failed". However, when ssh'ing in as admin@, I can't even do pkexec cockpit-bridge --privileged, I get

Authentication is required to perform privileged tasks with the Cockpit Web Console
Multiple identities can be used for authentication:
 1.  Administrator (admin)
 2.  fedora Cloud User (fedora)
Choose identity to authenticate as (1-2): 1
Password: 
polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ====
Error executing command as another user: Not authorized

Same for any other command. It feels like polkit itself is broken, as admin is clearly in the wheel group, and /etc/polkit-1/rules.d/50-default.rules ought to allow that. This needs a longer debugging session, I'm afraid.

[martinpitt]

With window.debugging = "all", one can see that it does try the sudo rule:

dbus: {"call":["/superuser","cockpit.Superuser","Start",["sudo"]],"id":"30"} 
dbus: {"error":["org.freedesktop.DBus.Error.Failed",["spawn failed"]],"id":"30"} 
Object { problem: null, name: "org.freedesktop.DBus.Error.Failed", message: "spawn failed", toString: toString() }

but it does not actually go on and try the polkit rule then. When I delete the sudo rule from /usr/share/cockpit/shell/manifest.json, it instead fails with

send 1:7 {"call":["/superuser","cockpit.Superuser","Start",["sudo"]],"id":"4"} 
recv 1:7: {"error":["org.freedesktop.DBus.Error.NotSupported",["No such superuser bridge"]],"id":"4"}

I.e. it still does not try to run the polkit bridge. Cockpit seems to have "sudo" hardcoded somewhere.

It works if one gives an explicit label to the polkit rule, like so:

cat <<EOF > cat /etc/cockpit/shell.override.json
{
    "bridges": [
        {
            "privileged": true,
            "label": "polkit",
            "spawn": [
                "pkexec",
                "--disable-internal-agent",
                "cockpit-bridge",
                "--privileged"
            ]
        }
    ]
}

@ananthb : That might be an acceptable workaround for you for the time being.

https://cockpit-project.org/guide/latest/packages.html#package-manifest even mentions that behaviour. @mvollmer , that feels a little strange to me, but I remember we discussed that a while ago. Was that a leftover work item that we just ignored/forgot? Or is that on purpose? But then, it does not really make sense to even add the polkit bridge in the default shell manifest, as it doesn't work anyway and can't easily be enabled in an override?

(test/verify/check-superuser also uses an explicit override)

[ananthb]

@martinpitt brilliant, thanks! I'm able to use admin mode without sudo installed with your workaround.

The systemd-homed error in my journal is a red-herring and is unrelated to this issue.

[mvollmer]

@mvollmer , that feels a little strange to me, but I remember we discussed that a while ago. Was that a leftover work item that we just ignored/forgot?

No, that was the compromise we arrived on. This allows people to use their own admin escalation methods without us having to change the default behavior of Cockpit. It's a bit complicated, but it does make sense once you have wrapped your head around it, I'd say.

But then, it does not really make sense to even add the polkit bridge in the default shell manifest, as it doesn't work anyway and can't easily be enabled in an override?

We left it there so that cockpit-desktop can run it by setting the COCKPIT_SUPERUSER environment variable.

[ananthb]

I might be missing some context, but I think its fair for cockpit to work in my scenario without extra configuration. If I have a working admin escalation method (i.e. polkit) available to my user, I expect cockpit to use that out of the box and not fail mysteriously. That's my two cents on this.

[abuGit]

Same bug on debian bookworm and sid. The shell.override.json"patch" does it. Thank you.

[TacitTactics]

I tried creating the suggested workaround json file, but no luck. Please provide more information as to how the workaround should be implemented. I am not familiar with polkit or cockpit. Thank you.

[ananthb]

@TacitTactics I just setup a new machine and the workaround still works. I hope you figured it out.

@martinpitt @mvollmer if you're still related to this, and you guys are okay with how this works, can we close the issue?

Are there docs I can add somewhere detailing the work-around to make polkit work.