Closed martinpitt closed 5 months ago
@travier FYI
LGTM then (with my limited knowledge of the code base) :)
Aww crap -- I broke this independently in https://github.com/cockpit-project/bots/pull/6348 - fixed in PR #20440
Update: rebased
This is an unrelated top flake.
@allisonkarlitskaya Verified, I added an integration test which kills the user service helper, and also strengthened the general cleanup check.
Since commit 644116a0cdaef53, the webserver certificates don't have to be owned by the cockpit-ws user/group any more. This allows us to use
DynamicUser
for cockpit.service, which eliminates the persistentcockpit-ws
system user.Note that we can't yet eliminate
cockpit-wsinstance
as that's the owner of ourcockpit-session
suid root binary.Spawned from #20365. This will eliminate at least half of the problem. PR #16811 was an attempt to do this for wsinstance, but this is much harder. #20365 is based on top of that to use sysusers.d for cockpit-wsinstance.
I tested this in Fedora both with upgrades from earlier versions and with a fresh install. If the user already exists statically, it will just be used. Otherwise, the service starts up fine now.
We actually cover both cases in our CI: Cockpit's VMs have cockpit-ws pre-installed and thus test "existing static user", while packit installs the package from scratch and tests the dynamic user case.