Closed martinpitt closed 7 years ago
This is from https://github.com/cockpit-project/cockpit/blob/master/src/reauthorize/reauthorize.c#L555
Indeed this is preceeded by
cockpit-session[31]: pam_reauthorize: couldn't create key in kernel session keyring: reauthorize/secret/martin: Operation not permitted
keyctl show
just fails in a container (as user and as root), so this is just a general limitation of containers as the kernel keyring isn't namespace aware. If using cockpit in a container is just not supported, then this issue should just be closed. If we do want to support it, then maybe providing a custom polkit agent might be better as it does not make assumptions about kernel capabilities?
Yup. The polkit agent stuff is currently being rewritten ... and the usage of the kernel keyring is being removed:
https://trello.com/c/HDtcZMu5/409-implement-a-polkit-agent-in-javascript
If you're interested in how the polkit agent currently works (until the rewrite is merged) then it's documented here: https://github.com/cockpit-project/cockpit/blob/master/doc/reauthorize.md
Rewrite has been merged, this shouldn't be an issue anymore
I installed cockpit into a fairly minimal F25 container:
On https://cockpit:9090/ (this requires
nss-mymachines
) I now tried to set a host name (by default the above only has a transient hostname acquired over DHCP). This shows a "/!\ Permission denied" error, and the log shows(this is with
G_MESSAGES_DEBUG=cockpit-ws,cockpit-bridge
).Running
hostnamectl set-hostname foo
in that container with the same user martin asks for my password via polkit and works, so polkit itself seems fine.