Bug#925552: release-notes: document problems with hidepid vs Buster systemd

[Justin B Rye]

Package: release-notes
Severity: wishlist
Tags: patch

The "hidepid" mount-options for /proc (as recommended by various
online hardening HOWTOs) work with Stretch but cause problems on
Buster, and are considered an unsupported configuration by systemd
upstream - see #819808, #892585, #897654. So users should probably be
advised to disable hidepid before doing a dist-upgrade.

Proposed text for issues.dbk:

<section id="hidepid-unsupported">
<!-- stretch to buster-->
<title>Hidepid mount options for procfs unsupported</title>
<para>
The hidepid mount options to <filename>/proc</filename> are known to cause
problems with current versions of systemd, and are considered by systemd
upstream to be an unsupported configuration. Users who have modified
<filename>/etc/fstab</filename> to enable these options are advised to
disable them before the upgrade, to ensure login sessions work on
&releasename;. (A possible route to re-enabling them is outlined on the
wiki's <ulink
url="https://wiki.debian.org/Hardening#Mounting_.2Fproc_with_hidepid">Hardening</ulink>
page.)
</para>
</section>

I can't claim to have tested the advice on that Hardening link on a
modern laptop running GNOME-on-wayland with pulseaudio and udisks2 and
network-manager and so on, but if it's wrong, we should correct the
wiki rather than the pointer.

-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[Debian Bug Tracking System]

Your message dated Tue, 26 Mar 2019 20:20:41 +0100
with message-id <47010659-93ed-120d-4cc7-***@debian.org>
and subject line Re: Bug#925552: release-notes: document problems with hidepid vs Buster systemd
has caused the Debian Bug report #925552,
regarding release-notes: document problems with hidepid vs Buster systemd
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)

[Andrei POPESCU]

Post by Justin B Rye
The "hidepid" mount-options for /proc (as recommended by various

Why plural? Both the wiki and proc(5) are using singular.

Thanks,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Justin B Rye
The "hidepid" mount-options for /proc (as recommended by various

Why plural? Both the wiki and proc(5) are using singular.

You're right - I was thinking of "hidepid=0/1/2" as separate options,
but yes, the approved terminology is to call it one option with
multiple possible arguments. I suppose I could argue that it's
only the non-zero arguments that cause problems rather than the
hidepid option itself, but no, here's a patch making it singular.

[Andrei POPESCU]

Post by Justin B Rye

Post by Andrei POPESCU

Post by Justin B Rye
The "hidepid" mount-options for /proc (as recommended by various

Why plural? Both the wiki and proc(5) are using singular.

You're right - I was thinking of "hidepid=0/1/2" as separate options,
but yes, the approved terminology is to call it one option with
multiple possible arguments. I suppose I could argue that it's
only the non-zero arguments that cause problems rather than the
hidepid option itself, but no, here's a patch making it singular.

:)

Post by Justin B Rye
diff --git a/en/issues.dbk b/en/issues.dbk
index 39d27b25..81ed5863 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -41,15 +41,15 @@ information mentioned in <xref linkend="morereading"/>.
<section id="hidepid-unsupported">
<!-- stretch to buster-->
- <title>Hidepid mount options for procfs unsupported</title>
+ <title>Hidepid mount option for procfs unsupported</title>
<para>
- The <literal>hidepid</literal> mount options for
- <filename>/proc</filename> are known to cause problems with current
- versions of systemd, and are considered by systemd upstream to be an
+ Using the <literal>hidepid</literal> mount option for
+ <filename>/proc</filename> is known to cause problems with current
+ versions of systemd, and is considered by systemd upstream to be an
unsupported configuration. Users who have modified
- <filename>/etc/fstab</filename> to enable these options are advised to
- disable them before the upgrade, to ensure login sessions work on
- &releasename;. (A possible route to re-enabling them is outlined on the
+ <filename>/etc/fstab</filename> to enable this option are advised to
+ disable it before the upgrade, to ensure login sessions work on
+ &releasename;. (A possible route to re-enabling it is outlined on the

Any particular reason for using "&releasename;" instead of "buster"?

At least for me it's easier to read (and understand) the source text
without so much markup.

Kind regards,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Justin B Rye
+ disable it before the upgrade, to ensure login sessions work on
+ &releasename;. (A possible route to re-enabling it is outlined on the

Any particular reason for using "&releasename;" instead of "buster"?
At least for me it's easier to read (and understand) the source text
without so much markup.

I'll just have been copying the prevailing markup features from
neighbouring sections..

Personally I would be happy to see &releasename; etc. eliminated in
any section that won't be kept for the buster->bullseye edition (and
the places that don't change should rarely mention releasenames).
It's not quite as bad as &debian;, which almost never makes sense,
since anybody recycling this document for (e.g.) Devuan would need to
change almost everything else, too.

But I've given up trying to get this sorted out, just as I've given up
asking why it is that we write "stretch" when the release announcement
called it "Stretch" and it's named after something called "Stretch"!

[Andrei POPESCU]

Package: release-notes
Severity: wishlist

Post by Justin B Rye

Post by Andrei POPESCU

Post by Justin B Rye
+ disable it before the upgrade, to ensure login sessions work on
+ &releasename;. (A possible route to re-enabling it is outlined on the

Any particular reason for using "&releasename;" instead of "buster"?
At least for me it's easier to read (and understand) the source text
without so much markup.

I'll just have been copying the prevailing markup features from
neighbouring sections..
Personally I would be happy to see &releasename; etc. eliminated in
any section that won't be kept for the buster->bullseye edition (and
the places that don't change should rarely mention releasenames).
It's not quite as bad as &debian;, which almost never makes sense,
since anybody recycling this document for (e.g.) Devuan would need to
change almost everything else, too.

It appears to be best practice in programming to use variables just
about everywhere.

In my opinion the same does not necessarily apply here because:

1. This is documentation

2. The source code itself is read by many, potentially non-programmers
(i.e. translators).

Turning this into a wishlist bug against the Release Notes, hopefully to
be considered for bullseye.

Kind regards,
Andrei

[Andrei POPESCU]

Package: release.debian.org
Severity: minor

Post by Justin B Rye
But I've given up trying to get this sorted out, just as I've given up
asking why it is that we write "stretch" when the release announcement
called it "Stretch" and it's named after something called "Stretch"!

Dear Release Team,

Apparently the code name for Debian releases has been used
inconsistently in various documentation and communication.

As the team delegated to (among many others) decide the code name of
Debian releases please kindly rule on the correct spelling (lower or
upper case), i.e. 'buster' or 'Buster'.

Many thanks,
Andrei