Unlock via PAM with Yubikey results in "No such file or directory"

[aschaap]

When trying out 0824841, I was unable to get PAM to unlock my home directory with a Yubikey plugged in, as indicated by the example. Adding a log parameter to the pam_exec.so command reveals:

Error: Failed to run zfs command for rpool/USERDATA/hunter
Error: No such file or directory (os error 2)

I'm on Ubuntu 20.04 with root on ZFS. I created rpool/USERDATA/hunter via shavee -y -c -z rpool/USERDATA/hunter. I manually set the mountpoint to /home/hunter and canmount to noauto (prevents asking for the password on boot). I also set overlay to on to get rid of the warning that the directory is not empty.

I am able to unlock the directory manually with shavee -y -z rpool/USERDATA/hunter.

[kiavash-at-work]

Hi @aschaap,

Thanks for reporting the issue. Just to be clear, before that specific PR, you were able to unlock properly? Could you please include your complete line for PAM unlock?

Thanks,

[kiavash-at-work]

BTW, would you mind to test 0.1.4 branch with latest PR #12 ?

[aschaap]

I do not seem to be able to unlock at all via PAM, 0.1.4 or HEAD^1 did not make a difference (0.1.4 had a less descriptive error message).

My /etc/pam.d/sddm line:

auth    optional        pam_exec.so log=/pam.shavee.log expose_authtok /usr/local/bin/shavee -p -y -z rpool/USERDATA

[kiavash-at-work]

auth    optional        pam_exec.so log=/pam.shavee.log expose_authtok /usr/local/bin/shavee -p -y -z rpool/USERDATA

Seems correct and I assume the user is hunter where rpool/USERDATA/hunter exists.

If you don't mind, would you do some tests and help us with their results?

On a terminal, can you please manually set PAM_USER

# export PAM_USER=hunter

and run this command?

# /usr/local/bin/shavee -p -y -z rpool/USERDATA

It is possible that it is the same as bug #7.

[aschaap]

@kiavash-at-work : Yes, the user is hunter and the dataset is rpool/USERDATA/hunter.

I have tried sudo PAM_USER=hunter /usr/local/bin/shavee -p -y -z rpool/USERDATA and what you suggested (as root, via sudo su), and the directory was mounted in both cases.

[kiavash-at-work]

Thank you. That was very helpful and it shows that the binary correctly parse PAM_USER env variable. It seems that it is needed to investigate why pam_exec.so hasn't passed that env variable as expected.

[aschaap]

But if the error message includes the username, wouldn't that mean the environment variable has been passed correctly? I tried with other directories and saw that the username was appended, so I'm confident that it is set and used as described.

[kiavash-at-work]

Very valid point and thanks for reminding me of the error message... maybe @ashuio have some ideas to help.

[kiavash-at-work]

Also, another possible root cause may be related to this issue when logging in a non-root user pam_exec.so doesn't have root privilege which is needed for ZFS mount.

[ashuio]

Sorry for being late, So as i understand the command is failing on the zfs_mount function when it tries to run the zfs load-key command.

First of all i'd suggest to try the 0.1.4 branch, The key derivation method has changed between the versions so you might wanna recreate the test directory with 0.1.4 build.

I will setup a ubuntu vm and test it.

If it is a permission problem it could be solved with adding the seteuid Option in pam_exec

[aschaap]

@ashuio I agree, I was able to track down the error message displayed to the zfs_mount call near the top of zfs.rs.

I'm looking forward to the outcome of your tests.

[ashuio]

@kiavash-at-work can you email me at shavee@ashu.io I'd like to discuss some things about this project if you're interested.

[ashuio]

@aschaap Can you give the new pam module int he 0.1.4 branch a go?

Replace with this in your pam file

auth optional "Path to the libshavee_pam.so file" -y -z rpool/USERDATA

Note: pam_exec.so also worked in my testing.

[ashuio]

I think this thread is resolved now with 0.1.4