Re: Who has rights to override/ignore systemd inhibitors?
On 21/08/15 17:14, Jayson Willson wrote:
> Hello. I have realized, that my user (groups:
> tty,disk,mail,news,dialout,voice,sudo,audio,www-data,video,plugdev,
> users,mlocate,kvm,vboxusers,libvirt)
> can ignore inhibitors (such as root being logged in) using "systemctl
> suspend/poweroff/etc -i"
Root being logged in is a factor that might (depending on policy)
prevent you from powering off, but it is not an inhibitor. An inhibitor
is a specific systemd-logind feature: when a program tells logind "don't
shut down until I say you can", that is an inhibitor.
org.freedesktop.login1.power-off-multiple-sessions is what might stop
you from shutting down while another user is logged in, and its default
policy is:
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
You will notice that "active" users (the user who is at the current
virtual console, if you are using fast user switching) can do this, by
default. This is because, if the user is local (physically present),
restricting the ability to shut down is an annoyance with no actual
security value: a physically present user could just unplug power and/or
remove a laptop battery, which is an implementation of shutdown that
clearly does not respect inhibitors.
If this default is unsuitable for your security policy (for instance
because your computer's power cable is not physically accessible by its
user), you can change it.
> I have asked in
> systemd-devel, why does it happen, and Lennart has answered, that
> authentication is handled by Polkit policy in file
> /usr/share/polkit-1/actions/org.freedesktop.login1.policy
That is part of it, but not the full story. If you have polkit from
unstable or older, .pkla files in /var/lib/polkit-1/localauthority and
/etc/polkit-1 are also relevant. (In theory someone could write a plugin
other than the "local authority" one, but in practice everyone uses that
plugin, which was originally just meant to be a reference implementation.)
With the newer polkit in experimental, JavaScript in
/usr/share/polkit-1/rules.d and /etc/polkit-1/rules.d is relevant instead.
Either way, it is possible to write rules in /etc to allow or deny
actions, overriding both the defaults in the .policy file and the
Debian-supplied rules in /var and /usr (which you can use as examples).
> without password prompt (with standard polkit
> configuration and without NOPASSWD in sudoers).
polkit does not run sudo, read sudoers, or understand sudoers syntax, so
whether you have NOPASSWD there is irrelevant. Its only relationship to
sudo is that both sudo and polkit, under their default configuration on
Debian, use the group named sudo to mean "this user is root-equivalent /
an administrator". It is not necessarily directly related to this
particular question, but if you don't want your user to be arbitrarily
powerful, don't put it in the sudo group.
The disk group is also highly inappropriate for a user that is not meant
to be root-equivalent, since it normally has access to the raw disk
devices for hard disks, and can bypass all access controls by (for
instance) editing the filesystem metadata of a shell to make it setuid-root.
If you want your user to not be root-equivalent, but you want to be able
to (for instance) edit the raw data of USB drives, I suggest a udev rule
in /etc/udev/rules.d/70yourname.rules. For instance this rule (which is
one long line) gives the active local user read/write access to all
USB-attached disk devices:
ACTION!="remove", ENV{MAJOR}!="", ENV{ID_BUS}=="usb",
SUBSYSTEM=="block", TAG+="uaccess"
S
Reply to: