Merge pull request #15376 from poettering/homed-btrfs-subvol-luks

[thirdparty/systemd.git] / man / pam_systemd_home.xml

diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml
index 6dc1a830b69e67d2db9b67f56429569dd3d9e2c8..5e3641c9035d3c404bd41e9efb29fc2f0cdb9191 100644 (file)
--- a/man/pam_systemd_home.xml
+++ b/man/pam_systemd_home.xml
@@ -51,8 +51,29 @@
         coming back from suspend. It is recommended to set this parameter for all PAM applications that have
         support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
         same user are open in parallel the user's home directory will be left unsuspended on system suspend
-        as long as at least one of the sessions does not set this parameter. Defaults to
-        off.</para></listitem>
+        as long as at least one of the sessions does not set this parameter to on. Defaults to
+        off.</para>
+
+        <para>Note that TTY logins generally do not support re-authentication on system resume.
+        Re-authentication on system resume is primarily a concept implementable in graphical environments, in
+        the form of lock screens brought up automatically when the system goes to sleep. This means that if a
+        user concurrently uses graphical login sessions that implement the required re-authentication
+        mechanism and console logins that do not, the home directory is not locked during suspend, due to the
+        logic explained above. That said, it is possible to set this field for TTY logins too, ignoring the
+        fact that TTY logins actually don't support the re-authentication mechanism. In that case the TTY
+        sessions will appear hung until the user logs in on another virtual terminal (regardless if via
+        another TTY session or graphically) which will resume the home directory and unblock the original TTY
+        session. (Do note that lack of screen locking on TTY sessions means even though the TTY session
+        appears hung, keypresses can still be queued into it, and the existing screen contents be read
+        without re-authentication; this limitation is unrelated to the home directory management
+        <command>pam_systemd_home</command> and <filename>systemd-homed.service</filename> implement.)</para>
+
+        <para>Turning this option on by default is highly recommended for all sessions, but only if the
+        service managing these sessions correctly implements the aforementioned re-authentication. Note that
+        the re-authentication must take place from a component runing outside of the user's context, so that
+        it does not require access to the user's home directory for operation. Traditionally, most desktop
+        environments do not implement screen locking this way, and need to be updated
+        accordingly.</para></listitem>
       </varlistentry>
 
       <varlistentry>