On Fri, 06 Jun 2025 at 15:40:20 +0200, Attila Szasz wrote:
Incidentally, I don't know how active user sessions in polkit and the
state of being a sudoer vs non-sudoer works when you hook up workstations
to AD, but it might be interesting.
Active vs. inactive vs. non-local user sessions in polkit are usually
orthogonal to whether you're root-equivalent, and are orthogonal to
whether your uid is defined by /etc/passwd or by some remote service.
If you logged in on the console (getty, xdm, gdm or similar) and your
session is still the one in the foreground (it wasn't put in the
background by "fast user switching" or Ctrl+Alt+function keys), then you
are said to have an active local session.
The interesting property of active local sessions in polkit is that by
default various services let them do certain restricted things in order
to meet reasonable user expectations, while not being fully
root-equivalent. For instance unprivileged users are not normally
allowed to shut down the machine (because that would compromise
availability), but unprivileged users with an active local session *are*
allowed to shut down the machine by default (on the assumption that a
user who is physically in front of the computer could usually equally
well cause denial of service by pulling the plug, so allowing them to
shut down gracefully does not make anything worse). This can be
overridden by local policy (the "pol" in the name polkit); for example
sysadmins of "kiosk" machines that are physically protected from
unauthorized disconnection should probably install local policy that
does not allow active local sessions to shut down.
Similarly, service authors and sysadmins can conditionalize any default
or non-default policy on whether a user has an active local session, if
they want to - and it would be technically possible to install a policy
that makes every active local user root-equivalent (live-boot images
might potentially want to do this), although that would be an unwise
thing to do on a general-purpose system.
If a user account's root-equivalence is given by group membership (e.g.
on Debian, the conventional way to allow privilege elevation to root is
by giving membership in the sudo group) then the decision to make it
root-equivalent or not could come from either local configuration, or AD
or similar remote services. If its root-equivalence comes from some
other property (e.g. editing /etc/sudoers) then it's more likely to be a
purely local fact.
smcv
