Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked
Package: user-setup Version: 1.83 Severity: normal User: de...@kali.org Usertags: origin-kali Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 the systemd-sulogin-shell binary run by rescue.service and emergency.service now adds the --force flag for the sulogin call when SYSTEMD_SULOGIN_FORCE is set to 1 in the environment. https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c explains that the expectation is that distributions should now put service override files to set this environment variable. Thus user-setup should create the appropriate configuration file when the root account is not configured. Maybe this should be controlled by some low priority debconf question as the password-less login through the rescue boot entry can be seen as a security issue by some. Cheers, -- System Information: Debian Release: bullseye/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages user-setup depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.73 ii passwd 1:4.8.1-1 user-setup recommends no packages. user-setup suggests no packages.
Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked
On Mon, 24 Feb 2020 17:38:53 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= wrote: > Package: user-setup > Version: 1.83 > Severity: normal > User: de...@kali.org > Usertags: origin-kali > > Following https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 > the systemd-sulogin-shell binary run by rescue.service and > emergency.service now adds the --force flag for the sulogin call > when SYSTEMD_SULOGIN_FORCE is set to 1 in the environment. > > https://github.com/systemd/systemd/commit/33eb44fe4a8d7971b5614bc4c2d90f8d91cce66c > explains that the expectation is that distributions should now > put service override files to set this environment variable. > > Thus user-setup should create the appropriate configuration file when > the root account is not configured. Maybe this should be controlled > by some low priority debconf question as the password-less login through > the rescue boot entry can be seen as a security issue by some. > There is https://salsa.debian.org/ah/user-setup/commits/wip/rootpassword thanks to Andreas. I'd suggest that people caring about that issue submit this as proper MR. Regards, Michael signature.asc Description: This is a digitally signed message part
Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked
Package: user-setup Followup-For: Bug #952450 Control: forwarded -1 https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6
Bug#952450: user-setup: set SYSTEMD_SULOGIN_FORCE=1 in env for rescue/emergency.service when root account is locked
Followup-For: Bug #952450 X-Debbugs-Cc: 1035...@bugs.debian.org, ty...@mit.edu As an experiment, I recently updated a functional Debian bookworm system to boot into the systemd 'rescue.target' by default, to test the single-user / recovery experience as part of #1035543 bug assessment. My understanding from the relevant manual[1] is that 'emergency.target' is a similar, albeit even more basic systemd state that is automatically selected if early boot preconditions fail and/or when serious errors occur. The system used for testing has a locked root user account, but is essentially a single-user environment, as I think is typical for many individually-operated laptops, smartphones and other consumer computing devices. There are various considerations to balance here, and because some of those are context/usage-specific, I agree with Raphaël that a debconf question to figure out the intended behaviour would make sense. My understanding of it is something like: "when your system breaks for some reason, are you ok with the next person who reboots it -- yourself or anyone else -- being able to access the contents and potentially attempt recovery?" Most of my experience with that scenario has been that either I or some other process has broken my computer, and I'd generally much prefer to be able to get to a recovery prompt without having to use other more time-consuming methods like removing the disk or finding other ways to get back into the system; but I can understand that those kind of choices vary person-to-person and over time. [1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html
