pkexec doesn't work inside a toolbox

[swick]

Running pkexec should work like sudo inside a toolbox but instead it fails:

⬢[swick@toolbox ~]$ pkexec test
Error getting authority: Error initializing authority: Exhausted all available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)

Worked around this issue in jhbuild but it would be great if pkexec just worked.

[matthiasclasen]

Are we sure that this is something that can be fixed up just with better toolbox configuration?

pkexec communicates with the polkit system service about pids and uids, and those are potentially different inside a container and outside. To me it looks like polkit would have to be made container-aware for this to have a chance of working.

[swick]

In the toolbox becoming root in the user namespace of the toolbox is not guarded by anything (sudo just succeeds without any authentication). pkexec equally works just like sudo except that it uses another system to authenticate users. We don't need or want authentication for pkexec, it should basically behave exactly like sudo.

So I think the best way to solve the problem is to replace pkexec with a script which takes the same arguments as pkexec and transforms them into arguments for sudo and then somehow make sure this script gets installed instead of the real pkexec.

[debarshiray]

Are we sure that this is something that can be fixed up just with better toolbox configuration?

pkexec communicates with the polkit system service about pids and uids, and those are potentially different inside a container and outside. To me it looks like polkit would have to be made container-aware for this to have a chance of working.

I haven't dug into PolKit or pkexec(1) much, but rootless Toolbx containers:

1. Don't have a PID namespace
2. Have the same $UID as on the host, but, not the same UID 0

Is that different UID 0 the problem here?

So I think the best way to solve the problem is to replace pkexec with a script which takes the same arguments as pkexec and transforms them into arguments for sudo and then somehow make sure this script gets installed instead of the real pkexec.

Do people have different expections from pkexec(1) than sudo(8) and do those differences matter here? People have asked for the ability to optionally set a password for sudo(8) or root in Toolbx containers. Will it cause problems if that happens?

[swick]

pkexec is a setuid program which asks org.freedesktop.PolicyKit1.CheckAuthorization for authorization. The service refuses to work when the UID of the caller is not 0:

Error checking for authorization org.freedesktop.policykit.exec: GDBus.Error:org.freedesktop.PolicyKit1.Error.NotAuthorized: Only trusted callers (e.g. uid 0 or an action owner) can use CheckAuthorization() and pass details

Is that different UID 0 the problem here?

So yes, that is indeed the problem and we can't work around this. That's why I'm suggesting to not even try and instead just change the binary to act like it always gets authorized.

Do people have different expections from pkexec(1) than sudo(8) and do those differences matter here?

I don't think so. They behave identically, it's just the way authorization works is different. If there is a functional difference I'm not aware of it.

People have asked for the ability to optionally set a password for sudo(8) or root in Toolbx containers. Will it cause problems if that happens?

That's a good question. When we make it wrapper for sudo pkexec will also just ask the user for a password... just in a different way. This should be fine.

pkexec also isn't used much anymore and really should not be used. I don't think we should spend too much time on it.

[debarshiray]

Thanks for the explanation, @swick !

So I think the best way to solve the problem is to replace pkexec with a script which takes the same arguments as pkexec and transforms them into arguments for sudo and then somehow make sure this script gets installed instead of the real pkexec.

I suppose one could do that in a way similar to Colin's idea here ?

[swick]

Indeed.