Re: systemd-inhibit don't work

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 10.08.20 um 15:37 schrieb Lennart Poettering:
> On Mo, 10.08.20 15:05, Reindl Harald (h.reindl@xxxxxxxxxxxxx) wrote:
> 
>> well, i would expect that the reboot in the scond ssh-session is
>> refused.......
>>
>> [root@master:~]$ /usr/bin/systemd-inhibit --what=shutdown --who=root
>> --why="Backup in progress" --mode=block sleep 600
>>
>> [root@master:~]$ /usr/bin/systemd-inhibit; systemctl reboot
>> WHO  UID USER PID COMM            WHAT     WHY                MODE
>> root 0   root 569 systemd-inhibit shutdown Backup in progress block
>>
>> 1 inhibitors listed.
>> [root@master:~]$ Connection to master.thelounge.net closed by remote host.
>> Connection to master.thelounge.net closed.
>> [harry@srv-rhsoft:~]$
> 
> Root is almighty on UNIX. This also means it has the privilege to
> ignore inhibitors, and thta's what you are seeing here.

tell that namesapces and gcroups :-)

my root user when doing from a graphical session "su - root" is far away
from almighty given he inherits the dropins for display-manager.service

> There is a github issue filed asking for some mechanism to extend
> inhibitors so that root can't trivially override it, but so far this
> hasn't been implemented.
sounds good

a backupserver with the only purpose running backups is the perfect
example for "nice that you instaleld some updates, but creep away and
reboot later when i am finished, no matter who you are"

dnf in one session doing upgrades and another admin in a different one
typing reboot would be another one

no question, he should be able to enforce it no matter what but not by
accident and i have around 5 things in mind where "you don#t reboot now"
would apply
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel