Talk:Systemd-homed

Enabling PAM modules: Don't make unnecessary changes to /etc/pam.d/system-auth

The PAM config on this page is copied from pam_systemd_home.8, but does not consider the other config files in /etc/pam.d. pam_loginuid and pam_keyinit should not be used by sudo [1][2] but will be if this config is used. Instead, the config should be something like the following to closer match the file from pambase [3]

#%PAM-1.0

auth      sufficient  pam_unix.so     try_first_pass nullok
-auth     sufficient  pam_systemd_home.so
auth      optional    pam_permit.so
auth      required    pam_env.so

-account  sufficient  pam_systemd_home.so
account   required    pam_unix.so
account   optional    pam_permit.so
account   required    pam_time.so

-password sufficient  pam_systemd_home.so
password  required    pam_unix.so     try_first_pass nullok sha512 shadow
password  optional    pam_permit.so

-session  optional    pam_systemd_home.so
session   required    pam_limits.so
session   required    pam_unix.so
session   optional    pam_permit.so

[1] https://linux.die.net/man/8/pam_loginuid

[2] https://linux.die.net/man/8/pam_keyinit

[3] https://github.com/archlinux/svntogit-packages/blob/packages/pambase/trunk/system-auth

Sambazley (talk) 19:06, 11 March 2020 (UTC)

This configuration leads to root being able to login without password. Just try logging in as root and pressing enter a few time instead of a password. Someone noticed it on reddit. NeoTheFox (talk) 19:12, 11 March 2020 (UTC)

How about:

#%PAM-1.0

auth      sufficient  pam_unix.so     try_first_pass nullok
-auth     sufficient  pam_systemd_home.so
auth      optional    pam_permit.so
auth      required    pam_env.so
auth      required    pam_deny.so

-account  sufficient  pam_systemd_home.so
account   required    pam_unix.so
account   optional    pam_permit.so
account   required    pam_time.so

-password sufficient  pam_systemd_home.so
password  required    pam_unix.so     try_first_pass nullok sha512 shadow
password  optional    pam_permit.so

-session  optional    pam_systemd_home.so
session   required    pam_limits.so
session   required    pam_unix.so
session   optional    pam_permit.so

Sambazley (talk) 20:17, 11 March 2020 (UTC)

Since you have required pam_deny.so, is optional pam_permit.so still relevant in this case? I found some discussion about removing pam_permit.so but that did not seem to go anywhere. Hexchain (talk) 10:38, 13 March 2020 (UTC)

The pam_systemd_home.so module should be used in all four types during authentication both on local and remote login (since 'sshd is to be supported), so just insert pam_systemd_home.so into all four types in /etc/pam.d/system_auth should be enough.

What's not quite clear is where to set the suspend=true option. As far as I understood pam_systemd_home(8):

'It is recommended to set this parameter for all PAM applications that have support for automatically re-authenticating via PAM on system resume.'

in every PAM-aware session locker's config, or DM one if it also acts as a locker, e.g.

/etc/pam.d/i3lock

auth   include login
-auth optional pam_systemd_home.so suspend=true

Or just add suspend=true to /etc/pam.d/system_auth auth section?

Skidnik (talk) 10:49, 12 March 2020 (UTC)

Don't try to add suspend=true to /etc/pam.d/system_auth. It will break the whole system up to being unable to log in as root.

—This unsigned comment is by Skidnik (talk) 15:14, 13 March 2020‎. Please sign your posts with ~~~~!

Lets sort out the PAM part in a visual way so that weird things not end up on the page:

From pam_systemd_home(8) effective PAM configuration must include:

pam_systemd_home(8) recommneds

#%PAM-1.0
auth      sufficient pam_unix.so
-auth     sufficient pam_systemd_home.so
auth      required   pam_deny.so

account   required   pam_nologin.so
-account  sufficient pam_systemd_home.so
account   sufficient pam_unix.so
account   required   pam_permit.so

-password sufficient pam_systemd_home.so
password  sufficient pam_unix.so sha512 shadow try_first_pass try_authtok
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

That is, effective doesn't mean it must be in one file.

This is an example of what can be effective with includes expanded from files as they are now in the pam-base package and commented:

/etc/pam.d/lightdm

#auth        include     system-login
auth       required   pam_tally2.so        onerr=succeed file=/var/log/tallylog
auth       required   pam_shells.so
auth       requisite  pam_nologin.so
##auth       include    system-auth
#end system-login
auth      required  pam_unix.so     try_first_pass nullok
auth      optional  pam_permit.so
auth      required  pam_env.so
-auth       optional    pam_gnome_keyring.so
##end system-auth

#account     include     system-login
account    required   pam_tally2.so 
account    required   pam_access.so
account    required   pam_nologin.so
##account    include    system-auth
#end system-login
account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so
##end system-auth

#password    include     system-login
##password   include    system-auth
password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so
##end system-auth
#end system-login

#session     include     system-login
session    optional   pam_loginuid.so
session    optional   pam_keyinit.so       force revoke
##session    include    system-auth
session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so
##end system-auth
session    optional   pam_motd.so          motd=/etc/motd
session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
-session   optional   pam_systemd.so
session    required   pam_env.so
#end system-login
-session    optional    pam_gnome_keyring.so auto_start

If you compare this resulting policy, you will see that every module pam_systemd_home(8) requires is present except for pam_systemd_home.so.

So all you need to do in /etc/mam.d/system-auth is add pam_systemd_home.so lines proposed in pam_systemd_home(8) and make pam_unix.so sufficient instead of required because it won't succedd if the user is not present in /etc/passwd which is the case with systemd-homed.

So the rsulting file should be:

/etc/pam.d/system-auth

#%PAM-1.0

auth      sufficient pam_unix.so     try_first_pass nullok
-auth     sufficient pam_systemd_home.so
auth      optional  pam_permit.so
auth      required  pam_env.so

account   sufficient pam_unix.so
-account  sufficient pam_systemd_home.so
account   optional  pam_permit.so
account   required  pam_time.so

-password sufficient pam_systemd_home.so
password  sufficient pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so

session   required  pam_limits.so
-session  optional   pam_systemd_home.so
session   required  pam_unix.so
session   optional  pam_permit.so

I'm placing the above to the page because with the current one there modules would end up loaded tiwce and pam_loginuid module ends up being used by sudo which breaks it's auditing.

Skidnik (talk) 15:12, 14 March 2020 (UTC)

As mentioned above, this configuration allows any user in passwd (whose shell is a real shell, such as root or git) to login without a password. Hexchain (talk) 15:23, 14 March 2020 (UTC)

I see. This is fixed by adding auth required pam_deny.so to the end of auth section. Will update the page accordingly. Skidnik (talk) 15:38, 14 March 2020 (UTC)

It brings back the question: whether pam_permit.so is still useful. It does not make much sense to still have it there because of the final pam_deny.so. I have opened https://bugs.archlinux.org/task/65819 to see if the maintainers have any opinion on this. Hexchain (talk) 16:00, 14 March 2020 (UTC)

As far as I understand it is there for logging in as nobody in case no username was set by the application more info in pam_permit(8). It returned success with both sufficient modules failing, thus allowing login. Now that we have a required module that fails the only ones that can ovverride that failure are sufficient modules. Skidnik (talk) 16:34, 14 March 2020 (UTC)

No, nobody should not be allowed to log in at all. What you said is the behavior of pam_permit when a user name is not provided, which is not relevant here. Hexchain (talk) 16:10, 15 March 2020 (UTC)

pam_permit is irrelevant for interactive logins' authentication, but /etc/map.d/system-auth may be used not only for that (do grep 'system-auth' /etc/pam.d/*). In the context of real user authentication it made no sense before, it still doesn't now. But for example there may be a not related to real user session service that needs no access whatsoever but needs interaction with PAM thus not setting the username at all and modules down the stack of its ruleset would still allow it to run as nobody or based on other checks not related to user management. Or there will be some wild application that won't set the username due to a bug and some PAM modules down the stack may react unpredictibly to that. pam_permit is there to prevent NULL usernames, it's a failsafe. Skidnik (talk) 18:27, 15 March 2020 (UTC)

I did a bit of investigation and it seems its only purpose is to provide a "landing point" for jumping over pam_unix.so, in auth [success=1 default=ignore] pam_krb5.so. See system-auth.in and basic-conf in this repository. The module was not there 10 years ago, which I believe is a reason why removing it is fine. Hexchain (talk) 18:47, 15 March 2020 (UTC)

How about this?

/etc/pam.d/system-auth

#%PAM-1.0

auth      [success=1 new_authtok_reqd=1 ignore=ignore user_unknown=ignore default=bad]  pam_systemd_home.so
auth      required  pam_unix.so     try_first_pass nullok
auth      optional  pam_permit.so
auth      required  pam_env.so
 
account   [success=1 new_authtok_reqd=1 ignore=ignore user_unknown=ignore default=bad]  pam_systemd_home.so
account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so
 
password  [success=1 new_authtok_reqd=1 ignore=ignore user_unknown=ignore default=bad]  pam_systemd_home.so
password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so
 
session   required  pam_limits.so
session   [success=1 new_authtok_reqd=1 ignore=ignore user_unknown=ignore default=bad]  pam_systemd_home.so
session   required  pam_unix.so
session   optional  pam_permit.so

Chandradeep Dey (talk) 15:49, 14 March 2020 (UTC)

Nevermind, this has a different issue upstream. https://github.com/systemd/systemd/issues/15116 Chandradeep Dey (talk) 16:03, 14 March 2020 (UTC)

This may look cleaner:

/etc/pam.d/system-auth

#%PAM-1.0

auth      substack    user-auth
auth      optional    pam_permit.so
auth      required    pam_env.so

account   substack    user-auth 
account   optional  pam_permit.so
account   required  pam_time.so

password  substack    user-auth 
password  optional  pam_permit.so

session   required  pam_limits.so
-session  optional   pam_systemd_home.so
session   required  pam_unix.so
session   optional  pam_permit.so

/etc/pam.d/user-auth

#%PAM-1.0

-auth     [success=done new_authtok_reqd=done default=ignore] pam_systemd_home.so
auth      [success=done new_authtok_reqd=done default=ignore] pam_unix.so try_first_pass nullok
auth      required pam_deny.so

-account  [success=done new_authtok_reqd=done default=ignore] pam_systemd_home.so
account   [success=done new_authtok_reqd=done default=ignore] pam_unix.so
account   required pam_deny.so

-password [success=done new_authtok_reqd=done default=ignore] pam_systemd_home.so
password  [success=done new_authtok_reqd=done default=ignore] pam_unix.so try_first_pass nullok sha512 shadow
password  required pam_deny.so

This way the substack 'user-auth' acts the same way as 'pam-unix.so' does in the original pam-base but includes both authentication mechanisms.

—This unsigned comment is by Skidnik (talk) 22:18, 15 March 2020‎. Please sign your posts with ~~~~!

[success=done new_authtok_reqd=done default=ignore] is just the long way of sufficient. This, together with pam_deny.so, brings back the debate you are having about pam_permit.so above.

In any case, we can't use success=done with pam_systemd_home.so on top of pam_unix.so just yet. The module returns PAM_SUCCESS on PAM_USER_UNKNOWN half the times. If #15118 is merged, we can use [success=1 new_authtok_reqd=1 ignore=ignore default=bad] which is almost required ([success=ok new_authtok_reqd=ok ignore=ignore default=bad]). required might be a better choice because both the modules can return different errors that we would otherwise be ignoring with sufficient. Chandradeep Dey (talk) 15:57, 16 March 2020 (UTC)

Closed the issue and the related pull request. I'm dumb and the issue wasn't really relevant. Here's my final system-auth and homed-substack based on messages with Skidnik on Telegram. The suspend=true parts don't work yet.

/etc/pam.d/system-auth

#%PAM-1.0

auth      substack  homed-substack
auth      required  pam_env.so

account   substack  homed-substack
account   required  pam_time.so

password  sufficient  pam_unix.so          try_first_pass nullok sha512 shadow
password  sufficient  pam_systemd_home.so
password  required    pam_deny.so

session   required  pam_limits.so
session   optional  pam_systemd_home.so  suspend=true
session   required  pam_unix.so

/etc/pam.d/homed-substack

#%PAM-1.0

auth      sufficient  pam_unix.so          try_first_pass nullok
auth      sufficient  pam_systemd_home.so  suspend=true
auth      [success=bad]  pam_permit.so

account   sufficient  pam_unix.so
account   sufficient  pam_systemd_home.so  suspend=true
account   required    pam_deny.so

Chandradeep Dey (talk) 11:13, 20 March 2020 (UTC)

I opened an issue asking for more documentation on the usage of the suspend=true flag. https://github.com/systemd/systemd/issues/15343.

Issue is tagged for v246 but hopefully we get answers before that. Thanks for all of your work so far figuring it out to this point :)

Jshap70 (talk) 15:42, 7 April 2020 (UTC)

Home directory locking on system suspend

Currently this is supported only for LUKS storage mechanism.

How do I expect this working: while logged in as a systemd-homed managed user with LUKS storage after issuing systemctl suspend and restoring from sleep, when switching to TTY and logging in as root I issue lsblk and don't see the user's home mount in the output.

I couldn't make this work: when I log in as root I see user's home directory mounted and can read files from user's home directory.

The pam_systemd_home(8) mentions a suspend= option which must be set to 'true' for any application that has support for re-authentication after system resume. I tried setting this option to 'true' for LightDM with light-locker activating on system suspention or for i3lock to no success: PAM or an application segfault.

Skidnik (talk) 08:39, 16 March 2020 (UTC)

Thanks to Jshap70 for opening the issue on systemd the question has been partially answered. Home directory locking is currently not supported by any DM as the session locking and user reauthentication has to be reimplemented in a way that it's not tied to the user session and does not require user home directory access.

Also rootless xorg support may be relevant as currently, judging from aforementioned open bug reports, all DMs except GDM start Xorg outside of logind session scope. Skidnik (talk) 10:14, 11 April 2020 (UTC)

Note that it's not true that it's not supported by any DM, while using GDM with wayland I was able to lock my user from a separate root tty login and the GDM lock screen was perfectly capable of re-authenticating and unlocking my home.

That said while messing around with the suspend=true and debug=true options I was still unable to get lock on suspend working. Suspending with it enabled would cause my system to seemingly hang while it tried to lock the user, and the computer never actually starts sleeping.

suspending from session

Apr 09 09:10:20 bebop systemd-homed[936]: Automatically locking home of user jshap.
Apr 09 09:10:20 bebop systemd-homed[936]: Locking home jshap.
Apr 09 09:10:20 bebop systemd-homed[936]: jshap: changing state active → locking
Apr 09 09:10:21 bebop systemd-homework[7527]: Discovered used LUKS device /dev/mapper/home-jshap.
Apr 09 09:10:21 bebop systemd-homework[7527]: File system synchronized.
Apr 09 09:10:21 bebop wpa_supplicant[1101]: wlp58s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=390000
Apr 09 09:10:21 bebop systemd-homework[7527]: LUKS device suspended.
Apr 09 09:10:21 bebop systemd-homework[7527]: Everything completed.
Apr 09 09:10:21 bebop systemd-homed[936]: jshap: changing state locking → locked
Apr 09 09:10:21 bebop systemd-sleep[7403]: Suspending system...
Apr 09 09:10:21 bebop kernel: PM: suspend entry (s2idle)
Apr 09 09:10:26 bebop systemd-logind[937]: Lid closed.
Apr 09 09:10:55 bebop systemd-logind[937]: Lid opened.
Apr 09 09:11:39 bebop systemd-logind[937]: Power key pressed.
Apr 09 09:11:43 bebop systemd-logind[937]: Power key pressed.
Apr 09 09:11:44 bebop systemd-logind[937]: Power key pressed.

I tried locking it manually from a root tty and I could see it never actually reached suspend or anything close: the tty was never even deactivated. Basically it gets stuck in some kind of loop trying to lock the home, and eventually all of your user processes have starved and are killed.

suspend from root tty

Apr 09 09:32:28 bebop wpa_supplicant[990]: wlp58s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-68 noise=9999 txrate=390000
Apr 09 09:32:28 bebop systemd-homed[846]: Automatically locking home of user jshap.
Apr 09 09:32:28 bebop systemd-homed[846]: Home jshap is already locked.
Apr 09 09:32:30 bebop wpa_supplicant[990]: wlp58s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-62 noise=9999 txrate=390000
Apr 09 09:33:12 bebop kernel: INFO: task tracker-store:3260 blocked for more than 122 seconds.
Apr 09 09:33:12 bebop kernel:       Tainted: G     U            5.6.3-arch1-1 #1
Apr 09 09:33:12 bebop kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 09 09:33:12 bebop kernel: tracker-store   D    0  3260   1420 0x00000080
Apr 09 09:33:12 bebop kernel: Call Trace:
Apr 09 09:33:12 bebop kernel:  ? __schedule+0x2e8/0x7a0
Apr 09 09:33:12 bebop kernel:  schedule+0x46/0xf0
Apr 09 09:33:12 bebop kernel:  rwsem_down_read_slowpath+0x20f/0x510
Apr 09 09:33:12 bebop kernel:  __percpu_down_read+0x4a/0x70
Apr 09 09:33:12 bebop kernel:  __sb_start_write+0xce/0xe0
Apr 09 09:33:12 bebop kernel:  mnt_want_write+0x20/0x50
Apr 09 09:33:12 bebop kernel:  do_unlinkat+0xf0/0x310
Apr 09 09:33:12 bebop kernel:  do_syscall_64+0x4e/0x150
Apr 09 09:33:12 bebop kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Apr 09 09:33:12 bebop kernel: RIP: 0033:0x7f0b09fc81db
Apr 09 09:33:12 bebop kernel: Code: Bad RIP value.
Apr 09 09:33:12 bebop kernel: RSP: 002b:00007ffc0c91ff08 EFLAGS: 00000246 ORIG_RAX: 0000000000000057
Apr 09 09:33:12 bebop kernel: RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0b09fc81db
Apr 09 09:33:12 bebop kernel: RDX: 00007f0afc00c230 RSI: 0000000000000001 RDI: 000055edf9d6f250
Apr 09 09:33:12 bebop kernel: RBP: 000055edf9d6f150 R08: 000055edf9d20012 R09: 0000000000000007
Apr 09 09:33:12 bebop kernel: R10: 000000000000002a R11: 0000000000000246 R12: 0000000000000000
Apr 09 09:33:12 bebop kernel: R13: 00007f0afc00f0a0 R14: 00007f0afc00f0a0 R15: 000055edf9d59720
Apr 09 09:33:58 bebop systemd-sleep[4545]: Failed to lock home directories: Connection timed out
Apr 09 09:33:58 bebop kernel: PM: suspend entry (s2idle)

Hibernation is even worse, it begins to hibernate, does actually properly lock the user, but then I was greeted by the GDM lock screen, and only after re-authentication did the system actually hibernate. And worse is that when I booted it back up I was dropped straight into my graphical session, no lockscreen....

journal looks like:

hibernating from session

...
Apr 09 09:22:37 bebop polkitd[935]: Unregistered Authentication Agent for unix-process:2452:60864 (system bus name :1.149, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Apr 09 09:22:38 bebop systemd[1]: Reached target Sleep.
Apr 09 09:22:38 bebop systemd[1]: Starting Hibernate...
Apr 09 09:22:39 bebop systemd-homed[846]: Automatically locking home of user jshap.
Apr 09 09:22:39 bebop systemd-homed[846]: Locking home jshap.
Apr 09 09:22:39 bebop systemd-homed[846]: jshap: changing state active → locking
Apr 09 09:22:39 bebop systemd-homework[2619]: Discovered used LUKS device /dev/mapper/home-jshap.
Apr 09 09:22:39 bebop systemd-homework[2619]: File system synchronized.
Apr 09 09:22:39 bebop systemd-homework[2619]: LUKS device suspended.
Apr 09 09:22:39 bebop systemd-homework[2619]: Everything completed.
Apr 09 09:22:39 bebop systemd-homed[846]: jshap: changing state locking → locked
Apr 09 09:22:39 bebop systemd-sleep[2495]: Suspending system...
Apr 09 09:22:39 bebop kernel: PM: hibernation: hibernation entry
Apr 09 09:23:28 bebop gdm-password][2630]: pam_systemd_home(gdm-password:auth): pam-systemd-homed authenticating
Apr 09 09:23:28 bebop systemd-homed[846]: jshap: changing state locked → unlocking-for-acquire
Apr 09 09:23:28 bebop systemd-homework[2636]: Provided password unlocks user record.
Apr 09 09:23:28 bebop systemd-homework[2636]: Discovered used LUKS device /dev/mapper/home-jshap.
Apr 09 09:25:51 bebop kernel: Filesystems sync: 49.217 seconds
Apr 09 09:25:51 bebop kernel: Freezing user space processes ... (elapsed 0.004 seconds) done.
Apr 09 09:25:51 bebop kernel: OOM killer disabled.
Apr 09 09:25:51 bebop kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
...
actually hibernates
...
Apr 09 09:25:51 bebop kernel: Restarting tasks ... done.
Apr 09 09:25:51 bebop systemd-homework[2636]: Resumed LUKS device home-jshap.
Apr 09 09:25:51 bebop systemd-homework[2636]: LUKS device resumed.
Apr 09 09:25:51 bebop systemd-homework[2636]: Everything completed.
Apr 09 09:25:51 bebop systemd-homed[846]: jshap: changing state unlocking-for-acquire → active
Apr 09 09:25:51 bebop gdm-password][2630]: pam_systemd_home(gdm-password:auth): Home for user jshap successfully acquired.
Apr 09 09:25:51 bebop gdm-password][2630]: gkr-pam: unlocked login keyring
Apr 09 09:25:51 bebop audit[2630]: USER_AUTH pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_tally2,pam_shells,pam_systemd_home,pam_permit,pam_gnome_keyring acct="jshap" exe="/usr/lib/gdm-session-worker" >
Apr 09 09:25:51 bebop kernel: audit: type=1100 audit(1586442351.816:160): pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:authentication grantors=pam_tally2,pam_shells,pam_systemd_home,pam_permit,pam_gnome_keyring acct="jshap" exe=">
Apr 09 09:25:51 bebop gdm-password][2630]: pam_systemd_home(gdm-password:account): pam-systemd-homed account management
Apr 09 09:25:51 bebop audit[2630]: USER_ACCT pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_tally2,pam_access,pam_systemd_home,pam_permit,pam_time acct="jshap" exe="/usr/lib/gdm-session-worker" hostname=bebo>
Apr 09 09:25:51 bebop kernel: audit: type=1101 audit(1586442351.833:161): pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:accounting grantors=pam_tally2,pam_access,pam_systemd_home,pam_permit,pam_time acct="jshap" exe="/usr/lib/gdm->
Apr 09 09:25:51 bebop audit[2630]: CRED_REFR pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_tally2,pam_shells,pam_systemd_home,pam_permit,pam_gnome_keyring acct="jshap" exe="/usr/lib/gdm-session-worker" hostnam>
Apr 09 09:25:51 bebop kernel: audit: type=1110 audit(1586442351.853:162): pid=2630 uid=0 auid=1000 ses=2 msg='op=PAM:setcred grantors=pam_tally2,pam_shells,pam_systemd_home,pam_permit,pam_gnome_keyring acct="jshap" exe="/usr/li>

So I suspect that there are some unit/authentication dependency problems for GDM at the moment, but haven't had the chance to look into them :(

Jshap70 (talk) 16:46, 11 April 2020 (UTC)

This is exactly what is meant by not supported. Setting suspend=true enables the home directory locking, but the system can not correctly suspend while it's locked. I observed the same behaviour with LightDM: lock screen appeared and home directory got locked but system never went to sleep until after I unlocked the session. Same behaviour both with suspend to RAM and to disk. Home directory lock requires changes to DM session locking mechanisms. Skidnik (talk) 17:23, 11 April 2020 (UTC)

(Auto)Mounts inside home directory

Not sure if this information is useful for the wiki and may be straightforward for others, but it took me some time to figure this out. When using homed systemd creates a home-username.mount. So for systemd automount and mount units to mount at the right time, in this case after the home directory has been mounted, they need

home-username-Games.automount

[Unit]
After=home-username.mount
…
[Install]
WantedBy=home-username.mount

Rautesamtr (talk) 10:19, 1 August 2020 (UTC)

SSH remote unlocking

While this works great (exactly as described), a missing feature is a passwordless (key-based) login when the user's home directory is already activated.

• This would require a somewhat magic feature that would reset sshd_config from AuthenticationMethods publickey,password back to AuthenticationMethods publickey for a user whose homedir is active. Unless I'm missing something, OpenSSH likely doesn't support anything of that kind; while one can specify multiple possible sets of login credentials, something like AuthenticationMethods publickey password,publickey (attempting to assume some client-side control over the necessity to supply a password) just doesn't work.

Additionally, with the configuration that I'm using (btrfs as filesystem type, with plain subvolumes and without any encryption (apart from a global LUKS setup irrelevant for systemd-homed)), it is technically feasible to activate any user's homedir without any password (or other input) from the user. root can mount (and access) all users' homedirs / subvolumes directly.

• I thought about incorporating something like homectl activate --no-ask-password %u into a script used as AuthorizedKeysCommand. Well, that doesn't work: It asks for a password nonetheless, albeit not every time; the password appears to be cached for a period of time and a few subsequent activates and deactivates work without a password, but eventually (and also initially) a password is needed.

Andrej (talk) 06:50, 29 September 2020 (UTC)

I simply replaced the comma (',') with a space, ironically in my new Debian system,

since this section is confusing if you're expecting for sshd to use your private key to mount your home directory. With every comma separated list in AllowedAuthorizationMethods, you'll need every authorization method in the list to log in, which makes passwordless login impossible the way the tip reads at the moment. Ectospasm (talk) 20:39, 6 April 2024 (UTC)

AuthorizedKeysCommandUser root

The example contains: "AuthorizedKeysCommandUser root". This is clearly not advised in the manpage: "It is recommended to use a dedicated user that has no other role on the host than running authorized keys commands." Ua4000 (talk) 12:24, 22 December 2020 (UTC)

unlock manually in case of dirty state

A few days ago my system crashed and the filesystem inside the luks got corrupt. There was no way login anymore and homectl was simply of no real use. It was solved by running

  homectl inspect <username>

this will show your Image Path (in my case /home/fabi.home) Now that this is known we can loop-device it with

  losetup -f -P <ImagePath> #/home/fabi.home

and of course open the crypt

  cryptsetup open <the_newly_created_loop_device> rescuehome

After this you're able to fsck the filesystem in there and that recovered my home.

I'd love to see this in an wiki, but I'm unable to write it down. So if someone wants to do it I would help. --Fabis.cafe (talk) 13:12, 14 January 2021 (UTC)

Hello, I actually encountered this problem myself and added it to the wiki page. The fact that currently systemd-homed doesn't provide instructions in its man page or that the homectl lacks a built-in command to attempt to recover from dirty states is, I think, pretty serious. Please feel free to add on or correct the content that I have added. Nu4425 (talk) 23:05, 16 October 2023 (UTC)

Although I haven't tested or personally encountered it, I actually don't see why dirty states shouldn't apply to removable medias (USBs) either because in principle file corruption can occur in either case. If someone can confirm this, I could clarify that in the wiki too. Nu4425 (talk) 23:11, 16 October 2023 (UTC)

I take my words back about file corruption due to dirty states applying to removable medias. According the man page for the homectl utility, the removable media backing storage mechanism is applied at the block level. This implies that there shouldn't be a loopback file that stores the data but only a .home file and a home directory of the user. Therefore file corruption of the loopback file would not occur, but it doesn't eliminate the possibility of not being in a dirty state Nu4425 (talk) 07:46, 22 October 2023 (UTC)