When a user is logged into Cockpit, they are logged into a normal session that has exactly the same privileges as if they logged in via SSH or on the console.
However, Cockpit will usually try to escalate the privileges of the user using Policy Kit or sudo. If the user is able to escalate privileges from the command line by typing in their password again (or without typing in any password), then Cockpit will be able to escalate the privileges of the session to "root" immediately upon login.
The user can change the privileges of a session from within that session, via the "Administrative access" indicator in the top bar. From that indicator, the user can drop "root" privileges and regain them. On the next login, Cockpit will give the session the same privileges.
Usually a user needs to be in the wheel Unix user group for the
user to be able to escalate privileges in this way. However both Policy Kit and
sudo may be configured to use other criteria.
Services like systemd
and NetworkManager use
Polkit to
validate and escalate privileges. It is possible to customize these rules with files
in /etc/polkit-1/rules.d.
Polkit rules files are
javascript with specific methods and objects. For example, placing the following polkit rule to
/etc/polkit-1.rules.d/10-operators.rule allows all users in the
operators group to start, stop, restart and otherwise manage systemd services:
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units") {
if (subject.isInGroup("operators")) {
return polkit.Result.YES;
}
}
});
In order to allow a certain group to perform any administrative action you could add a rule like this:
polkit.addAdminRule(function(action, subject) {
return ["unix-group:operators"];
});