Talk:Dm-crypt/Mounting at login

From ArchWiki
Jump to navigation Jump to search

pam_exec questions

Reading this interesting new contribution, I have three questions:

  1. Exposing the passphrase: Are there any downsides of using expose_authtok (for the time of the user session)? Is it feasible to clear it after mounting succeeded at the end of /usr/local/bin/securemount?
  2. Does this approach using pam_exec suffer from the same problem pam_mount has that a session is not closed due to pam_systemd.so (no consistent unmounting; see warning top of Pam_mount)?
  3. Since we don't have an fstab for the device, what about fsck-ing?

--Indigo (talk) 18:20, 27 February 2016 (UTC)

  1. AFAIK expose_authtok exposes it only to the proces executed by pam_exec, and this process is short-lived - it only mounts the partition, and then quits.
  2. No. Unmounting is not done in pam, it's done by systemd when user@.service gets stopped. And user@.service is usually stopped when the user logs out. (Usually? Because some daemons, like gpg-agent, may remain - and then it's not stopped. However, this is out of scope of this script, and should be solved in the systemd / DE configuration.)
  3. We can add fscking to the securemount script. I think it can be done by passing -ofsck to mount - therefore we may simply add another argument to securemount for passing mount options.

LEW21 (talk) 22:41, 27 February 2016 (UTC)

  1. Well, but the key @u stays active after mounting? Perhaps keyctl clear @u could be done upon unmounting. An alternative may be to add timeout to keyctl padd, particularly if (2) is an issue.
  2. I agree it should be solved in systemd. However, systemd sees it as NOTOURBUG, effectively breaking production status for pam_mount and pam_ecryptfs for some years & counting.[1] Nothing to do with your contribution. Yet, what I would like to avoid is that we add the user@.service method to a dm-crypt article and later figure it suffers from the same symptom, because this would break the whole concept of using it in the first place and users would be better off to stick with legacy mount helpers at login. You see the point? What do you think re the issue for the user service? (edit: It is not a consistent bug, but happens frequently. Simple way to test: login with the user, perform random tasks, log out again and check mounts with another user. If you do it 5-10 times and the user@.service always gets stopped/crypt unmounted, we're on a good path I'd say.)
  3. Hm, is that option alive? Anyway, e2fsck could be added by another optional ExecStart= in the mount service or something. --Indigo (talk) 04:19, 28 February 2016 (UTC)
  1. Password is stored in the kernel keyring of the root user until the computer gets turned of. I guess it's a good idea to add a timeout, and clear the key upon mounting successfuly (as it isn't needed anymore).
  2. pam_mount and pam_ecryptfs systemd-related bugs are different bugs. They unmount when PAM's session gets closed - and systemd does not close it correctly. I unmount when all the user's processes die - and unmounting before that happens is impossible, as they use the directory, and kernel wouldn't let it happen. Therefore, the thing that should get fixed, is stopping all user's services when he logs out. I guess I'll experiment a bit with it, and report results.
LEW21 (talk) 11:38, 28 February 2016 (UTC)
Thanks in advance for looking into it. I think the main caveat of the bug affecting pam_mount is that it will try only once to unmount and if that fails, it stays mounted. Such behaviour should be much better controllable with a systemd unit, if we can stipulate the requisites for it regarding user processes. It is logical the user cannot expect any user processes to run once he chooses to unmounts /home (log out). --Indigo (talk) 07:56, 6 March 2016 (UTC)

Article rewritten

I've rebuilt the solution from scratch, hopefully solving all the problems mentioned above. LEW21 (talk) 17:38, 24 January 2017 (UTC)

pam_exec required for session & using script

NOTE: Occurs with both GDM & LightDM, perhaps others.


Was unable to login with GDM, unless I first logged in on another tty using default shell, kept session opened, and switched back to GDM. After some poking around i found:

Default Shell (note: order of pam_unix calls)

Apr 14 13:11:09 o0o systemd[1]: Starting User Manager for UID 1000...
Apr 14 13:11:09 o0o kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
Apr 14 13:11:09 o0o login[3820]: pam_unix(login:session): session opened for user in0ni by LOGIN(uid=0)
Apr 14 13:11:09 o0o systemd[3951]: pam_unix(systemd-user:session): session opened for user in0ni by (uid=0)
Apr 14 13:11:09 o0o systemd-logind[254]: New session c2 of user in0ni.
Apr 14 13:11:09 o0o systemd[1]: Started Session c2 of user in0ni.
Apr 14 13:11:09 o0o systemd[3951]: Reached target Timers.

GDM Login (note: order of pam_unix calls)

Apr 14 13:10:03 o0o systemd[1]: Starting User Manager for UID 1000...
Apr 14 13:10:03 o0o systemd[1994]: pam_unix(systemd-user:session): session opened for user in0ni by (uid=0)
Apr 14 13:10:03 o0o systemd[1994]: Failed to fully start up daemon: Permission denied
Apr 14 13:10:03 o0o systemd-logind[260]: New session c2 of user in0ni.
Apr 14 13:10:03 o0o gdm-password][1955]: pam_unix(gdm-password:session): session opened for user in0ni by (uid=0)
Apr 14 13:10:03 o0o systemd[1]: Started Session c2 of user in0ni.
Apr 14 13:10:03 o0o systemd[1994]: Reached target Timers.
Apr 14 13:10:03 o0o systemd[1994]: Created slice Root Slice.

Having previously played with original pam_mount suggested, I decided to move pam_exec to system-auth, and use for both auth and session: (note: removal of expose_authtok in session)

#%PAM-1.0

auth [success=1 default=ignore] pam_unix.so try_first_pass nullok
auth      requisite pam_deny.so
auth      optional  pam_exec.so expose_authtok quiet /usr/bin/cryptsetup open /dev/sda2 home-USERNAME
auth      optional  pam_permit.so
auth      required  pam_env.so

account   required  pam_unix.so
account   optional  pam_permit.so
account   required  pam_time.so

password  required  pam_unix.so     try_first_pass nullok sha512 shadow
password  optional  pam_permit.so

session   optional  pam_exec.so quiet /usr/bin/cryptsetup open /dev/sda2 home-USERNAME
session   required  pam_limits.so
session   required  pam_unix.so
session   optional  pam_permit.so

Now pam_unix calls match that of the default shell

Apr 14 15:38:34 o0o systemd[1]: Starting User Manager for UID 1000...
Apr 14 15:38:34 o0o kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
Apr 14 15:38:34 o0o gdm-password][1867]: pam_exec(gdm-password:session): /usr/bin/cryptsetup failed: exit code 5
Apr 14 15:38:34 o0o gdm-password][1867]: pam_unix(gdm-password:session): session opened for user in0ni by (uid=0)
Apr 14 15:38:34 o0o systemd[1994]: pam_exec(systemd-user:session): /usr/bin/cryptsetup failed: exit code 5
Apr 14 15:38:34 o0o systemd[1994]: pam_unix(systemd-user:session): session opened for user in0ni by (uid=0)
Apr 14 15:38:34 o0o systemd-logind[246]: New session c2 of user in0ni.
Apr 14 15:38:34 o0o systemd[1]: Started Session c2 of user in0ni.
Apr 14 15:38:34 o0o systemd[1994]: Starting D-Bus User Message Bus Socket.
Apr 14 15:38:34 o0o systemd[1994]: Reached target Paths.
Apr 14 15:38:34 o0o systemd[1994]: Reached target Timers.

Suggested Changes:

To avoid several unnecessary calls to cryptsetup create /etc/pam_cryptsetup.sh (ensures it's called for the right user, and only if device not already open):

#!/bin/sh

CRYPT_USER="__INSERT_USER_NAME_HERE__"
MAPPER="/dev/mapper/home-"$CRYPT_USER

if [ "$PAM_USER" == "$CRYPT_USER" ] && [ ! -e $MAPPER ]
then
  /usr/bin/cryptsetup open /dev/sda2 home-$PAM_USER
fi

changes to system-auth:

auth      optional  pam_exec.so expose_authtok quiet /etc/pam_cryptsetup.sh
session   optional  pam_exec.so quiet /etc/pam_cryptsetup.sh

In0ni (talk) 21:16, 14 April 2017 (UTC)

Suggestion: Remove x-systemd.automount

Other units may trigger an automount request before you've logged in causing other programs to freeze. In my case both sddm and lightdm triggered automount requests to freeze for 1-2 minutes, even though I did as the article suggests by setting EnableAvatars to false in /etc/sddm.conf. Additionally NetworkManager triggered automount because, I assume, of connection configurations that refers to certificates and key-files in the home directory. I assume that other units may trigger autmount requests and freeze as well. In my case even logging in as another user and running vim (without referring to the automount point) triggered automount requests. Mapster (talk) 14:44, 14 October 2017 (UTC)


This bug is caused by the use of x-systemd.automount: https://bugs.archlinux.org/task/55043 The suggestions on this wiki page work without systemd automount. This may be a bug in x-systemd.automount. 00:55, 13 November 2017 (UTC)

pam LUKS partition auto mount on login returning exit code 2

These instructions no longer work. See https://bbs.archlinux.org/viewtopic.php?id=238477 . I don't know enough about how this works to say whether this is just a bug that needs to be fixed, or whether the workaround should be documented here. But this should get fixed somehow. JimRees (talk) 20:48, 10 July 2018 (UTC)

I don't know how it used to be, but expose_authtok provides the password with a \0 at the end, which doesn't work. I currently use a translator script that I call from pam_exec to work around the issue: cat - | tr '\0' '\n' | /usr/bin/cryptsetup open /dev/sda4 home-fabian DarkShadow44 (talk) 21:04, 13 July 2018 (UTC)
I haven't tried this, but I don't think you need the "cat", and it should be sufficient to just remove the nul byte: tr -d '\0' | /usr/bin/cryptsetup open /dev/sda4 home-fabian
This seems like a bug in expose_authtok. JimRees (talk) 13:25, 27 July 2018 (UTC)
Just tried the described instructions, and it worked like a charm. Mathieu.clabaut (talk) 14:49, 16 January 2019 (UTC)