Re: [systemd-devel] weird systemd-inhibit behaviour

2018-07-13 Thread Lennart Poettering
On Do, 28.06.18 22:24, Amish (anon.am...@gmail.com) wrote:

> It goes ahead and performs the action even if I am not using -i
> (--ignore-inhibitors) switch.
> 
> Documentation for -i (--ignore-inhibitors) states this:
> If any locks are taken, shutdown and sleep state requests will normally fail
> (regardless of whether privileged or not) and a list of active locks is
> printed.
> 
> It clearly states - "privileged or not" - so even if I am running systemctl
> as root - it should not shutdown or sleep in above case.

The docs are simply wrong on this one, please file a bug, so we fix them!

> Case 2)
> Inside graphical.target - using KDE plasma - logged in as a non-root user.
> 
> Same first command as in case 1).
> 
> # logged into KDE as non-root user but command below run as root inside
> konsole
> # systemd-inhibit 
> --what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown
> sleep 300 &
> 
> Now if I click KDE Menu-->Leave-->Suspend (Suspend to RAM) ... it blocks
> suspend and asks me for root password - stating that there is an inhibitor.
> 
> But if I click KDE Menu-->Leave-->Shut Down ... it goes ahead and shuts down
> the machine.

What happens if you run "systemctl -i poweroff" as unpriv user? Is
that honoured, or does that fail?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] weird systemd-inhibit behaviour

2018-06-28 Thread Amish

Hello

I am trying out systemd-inhibit as follows (on Arch Linux systemd 
version 238.133-4) but things dont seem to be working as expected.


So I would like to know if I am missing something or is there a bug?

Note: Everything is commented in /etc/systemd/logind.conf and there is 
no logind.conf.d directory in /run, /etc or /usr paths.


Case 1)
Inside multi-user.target - logged in to local tty as root.

# systemd-inhibit 
--what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown 
sleep 300 &

# systemd-inhibit --list
    Who: sleep 300 (UID 0/root, PID 2544/systemd-inhibit)
    What: 
shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch

 Why: Unknown reason
    Mode: block
...
$ echo switched to non-root user
$ systemctl suspend
Operation inhibited by "sleep 300" (PID 2544 "systemd-inhibit", user 
root), reason is "Unknown reason".

Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl suspend -i'.
# echo back as root user
# systemctl suspend # or halt or poweroff or reboot

It goes ahead and performs the action even if I am not using -i 
(--ignore-inhibitors) switch.


Documentation for -i (--ignore-inhibitors) states this:
If any locks are taken, shutdown and sleep state requests will normally 
fail (regardless of whether privileged or not) and a list of active 
locks is printed.


It clearly states - "privileged or not" - so even if I am running 
systemctl as root - it should not shutdown or sleep in above case.


Case 2)
Inside graphical.target - using KDE plasma - logged in as a non-root user.

Same first command as in case 1).

# logged into KDE as non-root user but command below run as root inside 
konsole
# systemd-inhibit 
--what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown 
sleep 300 &


Now if I click KDE Menu-->Leave-->Suspend (Suspend to RAM) ... it blocks 
suspend and asks me for root password - stating that there is an inhibitor.


But if I click KDE Menu-->Leave-->Shut Down ... it goes ahead and shuts 
down the machine.


/usr/lib/sddm/sddm.conf.d/sddm.conf has these systemctl commands 
mentioned in it:


HaltCommand=/usr/bin/systemctl poweroff
RebootCommand=/usr/bin/systemctl reboot

So I believe something is not right or I am doing something wrong in an 
unexpected way.


Case 2) may be KDE related issue but case 1) should atleast have worked 
as expected.


Can anyone else test?

Thank you,

Amish.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel