Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228978 > unrolled thread

Executing 'systemctl poweroff' from script run by cron.

Back to article view | Back to linux.debian.user

Contents

  Executing 'systemctl poweroff' from script run by cron. "Juan R. de Silva" <juan.r.d.silva@gmail.com> - 2020-11-24 00:00 +0100
    Re: Executing 'systemctl poweroff' from script run by cron. Reco <recoverym4n@enotuniq.net> - 2020-11-24 07:40 +0100
      Re: Executing 'systemctl poweroff' from script run by cron. <tomas@tuxteam.de> - 2020-11-24 10:10 +0100
        Re: Executing 'systemctl poweroff' from script run by cron. Reco <recoverym4n@enotuniq.net> - 2020-11-24 12:00 +0100
          Re: Executing 'systemctl poweroff' from script run by cron. Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-11-24 13:10 +0100
            Re: Executing 'systemctl poweroff' from script run by cron. <tomas@tuxteam.de> - 2020-11-24 13:20 +0100
            Re: Executing 'systemctl poweroff' from script run by cron. Fred <fred@blakemfg.com> - 2020-11-24 15:00 +0100

#228978 — Executing 'systemctl poweroff' from script run by cron.

I am running Buster after fairly deafult installation. One of my scripts 
executes '/usr/bin/systemctl poweroff' command. And I am having trouble 
executing this script from cron.

1. If run from user's CLI, the script succeeds.
2. If run from root crontab the script succeeds.
3. If run from user's crontab it fails with the following errors:

"Failed to set wall message, ignoring: Interactive authentication 
required.
Failed to power off system via logind: Interactive authentication 
required.
Failed to start poweroff.target: Interactive authentication required."

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.

2. Is there a way to get rid of this behaviour, since I prefer the script 
being executed by the user's cron job?

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.

Thanks.

[toc] | [next] | [standalone]

#228988

	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

[toc] | [prev] | [next] | [standalone]

#228993

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 24, 2020 at 09:32:49AM +0300, Reco wrote:
> 	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 [...]

Ugh.

Thanks for the gory details. You spoilt my breakfast ;-)

> 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.

I jumped off that wagon about that time where details were being
"ironed out": once, I pushed the power switch shortly, expecting
the system to power down... instead being presented a message that
I wasn't authorized to do that.

"What the heck?" thinks I "I have physical access to that box.
I could smash it with a sledgehammer".

Looking into the problem, I came to the conclusion that, as long
as I can keep my Debian box dbus-free, all other things I don't
like stay away too.

Yes, if I want to do videoconf these days I have to start Firefox
under apulse (they manage to maintain Firefox for three different
platforms, but for Linux they can't do alsa/pulseaudio: quite
hard for me to stick to Hanlon's Razor, but I try). Other apps
whine that they miss dbus. If I really care about them (Emacs,
I'm looking at you) I do compile them with dbus configured out.
Bluetooth. No bluetooth. I don't care.

But those are minor inconveniences.

Thanks (this time genuine thanks!) to people like you: you help
me to stay informed without having all the pain myself :-)

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#228996

	Hi.

On Tue, Nov 24, 2020 at 10:05:26AM +0100, tomas@tuxteam.de wrote:
> On Tue, Nov 24, 2020 at 09:32:49AM +0300, Reco wrote:
> > 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 [...]
> 
> Thanks for the gory details. You spoilt my breakfast ;-)

I really feel sorry for that.
But in this regard systemd is akin to many other things in life - it may
look pretty from the outside, but requires a strong stomach to peek
inside :)


> > 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.
...
> Thanks (this time genuine thanks!) to people like you: you help
> me to stay informed without having all the pain myself :-)

You're welcome!

Reco

[toc] | [prev] | [next] | [standalone]

#228998

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 24, 2020, 4:58 AM Reco <recoverym4n@enotuniq.net> wrote:

>         Hi.
>
> On Tue, Nov 24, 2020 at 10:05:26AM +0100, tomas@tuxteam.de wrote:
> .....
> >
> > Thanks for the gory details. You spoilt my breakfast ;-)
>
> I really feel sorry for that.
> But in this regard systemd is akin to many other things in life - it may
> look pretty from the outside, but requires a strong stomach to peek
> inside :)
>

It must be said: Kuhscheiß, bullshit.

Voices said that systemd was over-engineered before it was even really
available. Gigs of e-ink were spilled over that subject both before and
after its inclusion. Meanwhile it gets harder and harder to remove it due
to ineffective software compartmentalisation in systemd. It was simply a
poor choice.
And even Linus Torvalds makes mistakes. He's removed one of the main
systemd developers from kernel work, with good reason. But we still have
the software there.

Reco
>
>

[toc] | [prev] | [next] | [standalone]

#228999

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 24, 2020 at 06:05:14AM -0600, Nicholas Geovanis wrote:

[...]

> It must be said: Kuhscheiß, bullshit.
> 
> Voices said that systemd was over-engineered before it was even really
> available [...]

My take (if it matters at all) is that I don't like that overcomplex
design (not only systemd, mind you, but all that environment which
lead to it). But my take also is that it's not wise to wage a personal
war on it.

Other (much smarter) people do like the design and they deserve my
respect. So I keep my personal box at a safe distance (luckily this
is possible with Debian), but I acknowledge that the DE and systemd
people are making free software, too. More power to them!

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#229004

On 11/24/20 5:05 AM, Nicholas Geovanis wrote:
> 
> On Tue, Nov 24, 2020, 4:58 AM Reco <recoverym4n@enotuniq.net 
> <mailto:recoverym4n@enotuniq.net>> wrote:
> 
>              Hi.
> 
>     On Tue, Nov 24, 2020 at 10:05:26AM +0100, tomas@tuxteam.de
>     <mailto:tomas@tuxteam.de> wrote:
>     .....
>      >
>      > Thanks for the gory details. You spoilt my breakfast ;-)
> 
>     I really feel sorry for that.
>     But in this regard systemd is akin to many other things in life - it may
>     look pretty from the outside, but requires a strong stomach to peek
>     inside :)
> 
> 
> It must be said: Kuhscheiß, bullshit.
> 
> Voices said that systemd was over-engineered before it was even really 
> available. Gigs of e-ink were spilled over that subject both before and 
> after its inclusion. Meanwhile it gets harder and harder to remove it 
> due to ineffective software compartmentalisation in systemd. It was 
> simply a poor choice.
> And even Linus Torvalds makes mistakes. He's removed one of the main 
> systemd developers from kernel work, with good reason. But we still have 
> the software there.
> 
>     Reco
> 
Devuan is Debian with all traces of systemd removed.

Best regards,
Fred

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web