pam_systemd_home(8)

Takes an optional boolean argument. If yes or without the argument, the module will log debugging information as it operates.

Added in version 245.

.RE

.SH "HOME AREA SUPPORT"

.PP Home directories managed by systemd-homed.service(8) support multiple home "areas", which are additional secondary home directories of the user within the primary home directory. An example: at login time if a user lennart with a home directory of /home/lennart specifies lennart%versuch1 as account name during login, then pam_systemd_home will execute a login into lennart but ensure that the $HOME variable is set to /home/lennart/Areas/versuch1 instead of the usual /home/lennart.

.PP This is particularly useful when sharing the same home directory between multiple systems (for example between a host and a VM), with the desire to share the home directory to a large degree, but still have separate session configuration in place.

.PP Note that the default area to log into can also be encoded in the user record, and it can be specified among pam_systemd(8) configuration parameters. However, an explicit area specified at login time (via the % described above) overrides any such default. Also note that simply suffixing an account with % at login time (i.e. specifying an empty area name) has the effect of ensuring a login into the primary home directory, overriding any default area configuration via the user record or PAM.

.PP Note that not all login mechanisms are compatible with the % syntax at login time. Most notably ssh(8) is not.

.PP Note that the area directory to log into must exist for the area specification to be respected. If an area is specified during login via the % logic (or the other mentioned mechanisms) and it does not actually exist the request will be ignored, and the user will log into the primary home directory instead.

.PP Typically, in order to make use of the mechanism set up an area first, like this:

lennart@zeta$ mkdir -p ~/Areas
lennart@zeta$ cp -av /etc/skel ~/Areas/versuch1

.PP This should be enough to log into the newly created area, either via a regular terminal (using lennart%versuch1 when prompted for a user name), or via run0(1):

lennart@zeta$ run0 --area=versuch1

.SH "MODULE TYPES PROVIDED"

.PP The module implements all four PAM operations: auth (to allow authentication using the encrypted data), account (because users with systemd-homed.service user accounts are described in a JSON user record[1] and may be configured in more detail than in the traditional Linux user database), session (because user sessions must be tracked in order to implement automatic release when the last session of the user is gone), password (to change the encryption password — also used for user authentication — through PAM).

.SH "ENVIRONMENT"

.PP The following environment variables are initialized by the module and available to the processes of the user's session:

.PP $SYSTEMD_HOME=1

#%PAM-1.0


    -auth     [success=done authtok_err=bad perm_denied=bad maxtries=bad default=ignore] pam_systemd_home.so
auth      sufficient pam_unix.so
auth      required   pam_deny.so
account   required   pam_nologin.so
-account  [success=done authtok_expired=bad new_authtok_reqd=bad maxtries=bad acct_expired=bad default=ignore] pam_systemd_home.so
account   required   pam_unix.so
-password sufficient pam_systemd_home.so
password  sufficient pam_unix.so sha512 shadow try_first_pass
password  required   pam_deny.so
-session  optional   pam_keyinit.so revoke
-session  optional   pam_loginuid.so
-session  optional   pam_systemd_home.so
-session  optional   pam_systemd.so
session   required   pam_unix.so