Talk:Dm-crypt/Mounting at login

From ArchWiki
Jump to navigation Jump to search

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)