Talk:Dm-crypt/Mounting at login
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)
Why is this script in /etc, which is generally reserved for configuration files? This is a root-only executable, shouldn't it be in the sbin or /usr/sbin?
Osteichthyes (talk) 21:13, 27 June 2021 (UTC)
- /sbin and /usr/sbin are just symlinks to /usr/bin in Arch, and the /usr tree is intended for things provided by packages, not for administrator's modifications. — Lahwaacz (talk) 05:17, 28 June 2021 (UTC)
- How about /usr/local/sbin ? ? That's where local executables are supposed to go. I don't mean to be pedantic, but etc does not seem like an appropriate place for this script . Osteichthyes (talk) 05:31, 28 June 2021 (UTC)
- There are many scripts in /etc, e.g. /etc/security/namespace.init provided by pam itself. The directories in $PATH are intended for things that the user may run manually, which this script is not – it needs to be executed by the PAM module to do its thing based on the PAM environment variables. — Lahwaacz (talk) 05:44, 28 June 2021 (UTC)
Lock and unlock with systemd services
I was able to get this working with a systemd service.I'm pretty new to this, and unsure if this is done properly. So I didn't want to add it to the main page until someone who knows what they're doing looks over it at least.
[Unit] Before=user@<userid>.service BindsTo=user@<userid>.service [Service] User=<username> ExecStartPre=+/bin/cryptsetup open /dev/disk/by-uuid/<device-uuid> <device-label> --key-file=</path/to/key/file> ExecStart=+/bin/mount /dev/mapper/<device-label> <mount-dir> ExecStop=+/bin/umount <mount-dir> ExecStopPost=+/bin/cryptsetup close <device-label> Restart=always RemainAfterExit=yes [Install] WantedBy=user@<userid>.service
It will unlock/mount immediately after entering your password and before gnome(or I'd assume whichever DE) loads, and unmount/lock roughly 30s after logging out, and then restart waiting for you to log back in to mount again. You may need to edit logind.conf and enable something like KillAllUserProcesses. Not sure if that's the name. I'll figure it out before editing the main page. :p --Gdishun (talk) 13:40, 12 July 2020 (UTC)
- You forgot to sign ("~~~~").
- Where does the key file come from? JimRees (talk) 13:08, 12 July 2020 (UTC)
- You make one. Here is a walkthrough. https://www.howtoforge.com/automatically-unlock-luks-encrypted-drives-with-a-keyfile --Gdishun (talk) 13:40, 12 July 2020 (UTC)
This needs the key file being stored on an unencrypted storage, whereas the page deals with unlocking with the password used for the actual login. -- Lahwaacz (talk) 22:08, 2 April 2021 (UTC)
Service "home-username.mount" fails to mount if filesystem type is ext4 instead of btrfs
As the tile says, the service fails to mount if "Type=btrfs" is changed to "Type=ext4". The error is something along the lines of "systemd failed to mount: wrong fs type, bad superblock" etc etc.
Note that "Type=btrfs" will also fail to mount if we don't install the btrfs-progs package beforehand and use mkfs.btrfs to create the file system.
I would really prefer to use ext4 but I don't know how to get it working. So for now, btrfs will have to do.
—This unsigned comment is by Coldfourtold (talk) 2022-04-16T05:16:54. Please sign your posts with ~~~~!
Does this still work with luks2?
Is this still working for folks? I have used this setup a bunch of times, and it's recently stopped working for me. I won't go into the details here, as I've laid them out here: https://bbs.archlinux.org/viewtopic.php?id=281467
I was trying to figure out what is different about this implementation from past implementations and it occurred to me that I'm using luks2 for the first time -- can anyone confirm the systemd unit that locks the device installs with luks2? Osteichthyes (talk) 02:18, 23 November 2022 (UTC)
Is this page a hacky version of the Pam_mount ?
There's the Pam_mount wiki page about unlocking partitions on login, shouldn't it be preferred as it appears to be an official way to do so ?