On Sb, 10 apr 21, 10:53:52, Justin B Rye wrote:
> Andrei POPESCU wrote:
> > Ok, here is something, just to get the discussion started:
>
> Thanks! My suggestions below still need some work, but I'll call this
> my first pass:
>
> > The `rescue` boot option is unusable without a root password.
> >
> > If a password for the `root` account is not set the system will
> > still ask for the root password if booted with the `rescue` option,
> > effectively making the rescue mode unusable. In order to avoid this
> > it is possible to boot using the kernel parameter
> > `init=/sbin/sulogin --force`.
>
> Simplifying:
>
> <title>
> The <literal>rescue</literal> boot option is unusable without a root password
> </title>
> <para>
> Booting with the <literal>rescue</literal> option always requires
> the root password. If one has not been set, this makes the rescue
> mode effectively unusable. However it is still possible to boot
> using the kernel parameter <literal>init=/sbin/sulogin --force</literal>
> </para>
>
> (I don't think "root" needs special markup; "rescue" only needs it
> when we're talking about an untranslatable literal string).
Ok
> (Should there be some hint here at the fact that this has happened
> because we've switched to an implementation of sulogin without the
> slightly dodgy Debian-specific patches?)
This is explained in the bug report for who cares to investigate, in my
opinion it's not needed in the Release Notes.
> > To configure pkg:systemd to always to do the equivalent of this on
> ^^^ ^^ ^^
> When we're talking about machines booting with systemd-sysv, we should
> avoid mentioning <systemitem role="package">systemd</systemitem>
> (which is a pain to type anyway).
>
> The "to" might go in either position, but not both. Here perhaps we
> might be better off saying
It's a consequence of some rewrite :)
> To configure systemd to do the equivalent of this whenever the
> <literal>rescue</literal> option is used,
>
> > selecting the `rescue` option add `SYSTEMD_SULOGIN_FORCE=1` to the
> > Environment of the rescue.service unit (see
> > file:/usr/share/doc/systemd/ENVIRONMENT.md.gz). The `rescue.service`
>
> At least this information is already on my system before the
> dist-upgrade.
>
> > unit is started by pkg:systemd in case it detects `single` in the
> ^^^^^^^
> > kernel command line (see man:systemd).
>
> Bad use of "in case" - most English-speakers interpret "in case of" as
> "unconditionally, to avert the danger of".
I'll have to trust you on this (and make a mental note about it).
> systemd(1) defines "single" and "rescue" (and "1"!) as aliases of
> "systemd.unit=rescue.target", so maybe we can make that clearer
> earlier.
>
> <para>
> To configure systemd to do the equivalent of this whenever it
> boots into rescue mode (also known as single mode - see <ulink
> url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>),
> add <literal>SYSTEMD_SULOGIN_FORCE=1</literal> to the
> Environment of the <literal>rescue.service</literal> unit (see
> <filename>/usr/share/doc/systemd/ENVIRONMENT.md.gz</filename>).
> </para>
>
> Unfortunately we also need readers to know
> * how to add things to a systemd unit (we don't want people editing
> /lib/systemd/system/rescue.service and losing it in an upgrade)
> * how much of the rest of the file they should copy (as little as
> possible, I think, but how much is that?)
> * how the syntax for multiple items in an Environment= line works
>
> This probably needs an external link, but I'm not optimistic we'll
> find one. Maybe this is another case where we'll need a dedicated
> page on wiki.debian.org.
As you probably know, it's as simple as:
systemctl edit rescue.service
and add
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
It seemed a little bit much to add this as well, but I'm fine either
way.
> (And why *is* the systemd man page in section 1, anyway? Shouldn't it
> be in section 8, like systemv init used to be?)
>
> > It might be useful to do the same for the `emergency.service` unit
> > (or instead) which is started ''automatically'' in case of certain
> ^^^^^^^^^^ ^^^^^^^^^^
> > errors (see man:systemd.special), or if `emergency` is added to the
> > kernel command line (e.g. in case the system can't be recovered by
> ^^^^^^^
> > using the `rescue` mode).
>
> "The same or instead" needs to be reorganised as "as well or instead".
>
> One of those "in case"s almost works.
>
> I'm not sure what markup you mean for ''automatically''.
Some form of emphasis, to draw attention to the fact that users might
find themselves stuck at the emergency console.
> <para>
> It might be useful to do this for the <literal>emergency.service</literal>
> unit (as well or instead), which is started automatically in the case
> of certain errors (see <ulink
> url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>),
> or if <literal>emergency</literal> is added to the kernel command line
> (e.g. if the system can't be recovered by using the rescue mode).
> </para>
>
> (Why *did* setting these systems up with passwords in the first place
> go out of fashion?)
For me it was a natural consequence of using sudo exclusively ;)
> > For background and a discussion on the security implications see
> > bts:802211.
>
> I forget if we've got special markup for this or whether we just say
All entities are in a dedicated file (I don't have a checkout handy to
look it up).
> <para>
> For background and a discussion on the security implications see
> <ulink url="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211";>bug
> #802211</ulink>.
> </para>
>
> Or even delegate it to the wiki link. Oh well, buster needed two
> last-minute wiki pages for complicated issues, so if bullseye only
> needs one for this we'll still be improving...
This is actually applicable for buster as well, unfortunately it wasn't
fixed for bullseye (patch for d-i was still pending last time I
checked).
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature