Re: Executing 'systemctl poweroff' from script run by cron.
Hi.
On Mon, Nov 23, 2020 at 10:55:50PM -0000, Juan R. de Silva wrote:
> 1. Why, when the script is run by the user cron job, the execution
> requires authentication, while run from the same user terminal, it does
> not.
What "systemctl poweroff" actually does (src/systemctl/systemctl.c,
halt_main()) is first checks if the calling user is root. If this check
fails it sends DBUS message to logind to see if a calling user is
allowed to call poweroff.
In the absence of PolicyKit logind's check will only succeed if the
user's systemctl is a part of a current "session" attached to a
"console". I.e. it's OK to shutdown a host from VT or an X session, but
it's big "no" from ssh or cron.
In the presense of PolicyKit user's systemctl may be still allowed the
action if the user supplies a root password to PolicyKit.
tl;dr version - the authentication always happens, but it bothers you
only if it fails.
> 2. Is there a way to get rid of this behaviour, since I prefer the script
> being executed by the user's cron job?
There's no easy way short of rewriting systemd or writing your own
PolicyKit policy which will allow non-interactive user processes to do
anything via systemctl.
You can always call "sudo systemctl poweroff" in your cron job, but such
approach opens its own, bigger can of worms.
> 3. I am also surprised that 'systemctl poweroff' command can be executed
> either directly from the user's terminal or by running a script without
> any authentication request. There's certain inconsistency here, isn't it?
> IMHO, it does not feel like a safe approach.
It's a FreeDesktop standard, believe it or not.
A user should be allowed to reboot or poweroff the computer which they
have direct console access.
Reco
Reply to: