Skip to content

Commit

Permalink
sulogin-shell: Use force if SYSTEMD_SULOGIN_FORCE set
Browse files Browse the repository at this point in the history
When the root account is locked sulogin will either inform you of
this and not allow you in or if --force is used it will hand
you passwordless root (if using a recent enough version of util-linux).

Not being allowed a shell is ofcourse inconvenient, but at the same
time handing out passwordless root unconditionally is probably not
a good idea everywhere.

This patch thus allows to control which behaviour you want by
setting the SYSTEMD_SULOGIN_FORCE environment variable to true
or false to control the behaviour, eg. via adding this to
'systemctl edit rescue.service' (or emergency.service):

[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1

Distributions who used locked root accounts and want the passwordless
behaviour could thus simply drop in the override file in
/etc/systemd/system/rescue.service.d/override.conf

Fixes: #7115
Addresses: https://bugs.debian.org/802211
  • Loading branch information
andhe authored and poettering committed Oct 17, 2018
1 parent d86c8a6 commit 33eb44f
Show file tree
Hide file tree
Showing 2 changed files with 16 additions and 1 deletion.
6 changes: 6 additions & 0 deletions docs/ENVIRONMENT.md
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,12 @@ systemd-timedated:
first existing unit listed in the environment variable, and
`timedatectl set-ntp off` disables and stops all listed units.

systemd-sulogin-shell:

* `$SYSTEMD_SULOGIN_FORCE=1` — This skips asking for the root password if the
root password is not available (such as when the root account is locked).
See `sulogin(8)` for more details.

bootctl and other tools that access the EFI System Partition (ESP):

* `$SYSTEMD_RELAX_ESP_CHECKS=1` — if set, the ESP validation checks are
Expand Down
11 changes: 10 additions & 1 deletion src/sulogin-shell/sulogin-shell.c
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@
#include "bus-util.h"
#include "bus-error.h"
#include "def.h"
#include "env-util.h"
#include "log.h"
#include "process-util.h"
#include "sd-bus.h"
Expand Down Expand Up @@ -89,7 +90,11 @@ static void print_mode(const char* mode) {
}

int main(int argc, char *argv[]) {
static const char* const sulogin_cmdline[] = {SULOGIN, NULL};
const char* sulogin_cmdline[] = {
SULOGIN,
NULL, /* --force */
NULL
};
_cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
int r;

Expand All @@ -99,6 +104,10 @@ int main(int argc, char *argv[]) {

print_mode(argc > 1 ? argv[1] : "");

if (getenv_bool("SYSTEMD_SULOGIN_FORCE") > 0)
/* allows passwordless logins if root account is locked. */
sulogin_cmdline[1] = "--force";

(void) fork_wait(sulogin_cmdline);

r = bus_connect_system_systemd(&bus);
Expand Down

7 comments on commit 33eb44f

@imthenachoman
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize this is a very old thread but, from what I can tell, its still the normal behavior with Debian and I had an idea.

As discussed the --force option is not very secure.

Instead, why not change the systemd scripts to open a shell as a regular user who has login and sudo as root privileges? Like a system admin maybe. That way they can login with their ID and then use sudo to become root -- which would require their password again.

This seems like a far better and more secure option then currently prescribed which is either to use --force or to not lock the root account.

@yuwata
Copy link
Member

@yuwata yuwata commented on 33eb44f Jan 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about this, but please file as an issue or submit a PR for that. Otherwise, almost no one can find your comment and this is easily forgotten.

@imthenachoman
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll submit an issue. Thanks!

@shmerl
Copy link

@shmerl shmerl commented on 33eb44f Dec 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@imthenachoman: which issue was it? Just wanted to track it.

@imthenachoman
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shmerl I never opened one. There was an active discussion on #11596 and I concluded my idea was not a good one. :/

@shmerl
Copy link

@shmerl shmerl commented on 33eb44f Dec 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think current alternative (complete root without any password prompt, when SYSTEMD_SULOGIN_FORCE=1 was set) is even worse. Some kind of authentication at that step would be better than none at all. Looking at that discussion, I'm not sure what the conclusion is. That it's not necessary, or it's not clear how to do it?

Can auth be performed against a particular user, to simply run something like sudo su, without dealing with $HOME for that user at all?

@imthenachoman
Copy link

@imthenachoman imthenachoman commented on 33eb44f Dec 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think anything is possible but it would require a lot of pre-requisites/pre-work and it isn't worth the effort for the developers. I assume...

Please sign in to comment.