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.

[rickhull]

I have this issue on Arch 6.12.7.

The workaround worked for me. I think there is a bug in it though:

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

the second cat in the first line shouldn't be there

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

[Imeguras]

I seemingly have a similar issue, same background except it responds should i start a new issue? Also i've attempted to add doas in every way but im stuck is there any documentation for doas or less conventional authentication schemes(such as polkit and sudo)

[mvollmer]

I think the current behavior of Cockpit is the result of these considerations:

• We don't want to try a number of different privilege escalation methods just in the hope that they might work.
• By default, we also don't want to make the user select which method to use.
• This means we need pick a single one (by default).
• Right now this is "sudo" because we think it's "the standard".
• But there is code in Cockpit for polkit, and we test it.
• There is also enough configurability for people to switch to polkit, or indeed enable multiple methods and let the user chose each time.

What else is needed?

[rickhull]

I don't understand why this was closed. I don't think there is a config item for this, unless you are saying that my "workaround" is the expected way for the user to deal with the obstacle.

Unless I misunderstand, this is the repro:

1. Linux system without sudo
2. Attempt administrative function in Cockpit
3. Error, with no indication for how to resolve

Is this the desired behavior?

[mvollmer]

I don't understand why this was closed.

Mostly to provoke a reaction... Let's reopen.

I don't think there is a config item for this, unless you are saying that my "workaround" is the expected way for the user to deal with the obstacle.

Yes, this is the configurability I was mentioning. I am thinking that it's not necessarily going to be the user that is doing the configuration, but more likely the sysadmin (the one that implements the policy for escalating privileges and removes sudo in the process), or the OS vendor.

I recognize that sudo might not be as much "the standard" as we think it is, and it certainly isn't great. So do you think we need to make it easier out of the box to switch to polkit, doas, etc?

How could that look? I am really quite hesitant right now to let Cockpit discover at run-time what might or might not work. I think it is better to configure this explicitly.

Maybe a config option in cockpit.conf that you could set to "polkit" and then Cockpit would use the polkit bridge instead of "sudo"?

[mvollmer]

Maybe a config option in cockpit.conf that you could set to "polkit" and then Cockpit would use the polkit bridge instead of "sudo"?

(It's probably going to be "pkexec" instead of "polkit" if we don't change how Cockpit identifies different privileged bridges.)

[mvollmer]

In the backlog now: https://issues.redhat.com/browse/COCKPIT-1321