That does indeed seem to be the case. It appears that my distro activated a temporary directory override recently, and I already had /tmp mounted as NOEXEC.
Bug report for my distro for anyone that comes across this: https://github.com/Kicksecure/security-misc/issues/198 Thank you On Friday, February 2nd, 2024 at 7:39 PM, Guilhem Moulin - guilhem at debian.org <guil...@debian.org> wrote: > > > Control: tag -1 moreinfo > > Hi, > > On Fri, 02 Feb 2024 at 18:44:43 -0500, abrasamji wrote: > > > update-initramfs log excerpt with set -x: > > > > Calling hook cryptkeyctl > > + PREREQ=cryptroot > > + . /usr/share/initramfs-tools/hook-functions > > + [ ! -x > > /tmp/user/0/mkinitramfs_LhQz6c/lib/cryptsetup/scripts/decrypt_keyctl ] > > + exit 0 > > > > A check with ls -la while update-initramfs was running, prior to > > cryptkeyctl being executed, in order to prove it's presence: > > > > /tmp/user/0/mkinitramfs_LhQz6c/usr/lib/cryptsetup/scripts: > > total 4 > > drwxr-xr-x 2 root root 60 Feb 2 17:44 . > > drwxr-xr-x 3 root root 100 Feb 2 17:44 .. > > -rwxr-xr-x 1 root root 2042 Apr 20 2023 decrypt_keyctl > > > > I changed the '-x' flag in the if statement to a '-s' flag. This fixed > > it and I don't know why, and I don't know if its a bug in initramfs, > > dash, or cryptsetup or something else. > > > Seems like your update-initramfs is running under TMPDIR=/tmp/user/0, is > is perhaps mounted with the ‘noexec’ flag set? > > That would cause `test -x` to fail on an existing path with the exec bit > set, and per mkinitramfs(8) this not supported: > > ENVIRONMENT > > mkinitramfs honours the TMPDIR environment variable. If set, it > uses subdirectories in the given directory to create its > temporary working directories. Else it uses /var/tmp as default > value for that purpose. The given directory should be on a > filesystem which allows the execution of files stored there, i.e. > should not be mounted with the noexec mount option. > > -- > Guilhem.
