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.

While testing 0.1.4 branch (9089e755a62c9585fe24b129d1e0b87200d8b20d), (most definitely main branch has the same bug too) I noticed that an unexpected error happens with this command line. Only if PAM_USER environment variable is not set.

$ ./shavee unexpected --pam -z testpool/testdataset
thread 'main' panicked at 'Panic! Something unexpected happened! Please help by reporting it as a bug.: NotPresent', shavee-bin/src/args.rs:198:55

This seems to be caused by a corner case when the binary is executed in PAM mode while passing an unexpected argument to the binary. Clap fails to reject it correctly.

It seems that this section causes Clap to replace PAM_USER with unexpected argument, instead of providing error for lack of the existence of PAM_USER environment variable.

Then here PAM_USER is being used while it doesn't exists and throws a Panic!

Unit test didn't catch it because it sets PAM_USER environment.

If the plan is that 0.1.4 branch will have a separate libpam_shavee.so instead of --pam PAM mode, then it should be better to to move PAM_USER validating and appending it to the dataset to this PAM module and remove it from the main binary argument.

This is a fast and dirty attempt to refactor as much code as possible to make CLI binary and PAM module arguments use the common functions minimizing the duplicate codes.

I have only sanity checked it and didn't test against all possible combinations.

Currently, the hash generation happens after user entered password, however these can happen in parallel meaning while it is waiting for the user is to enter password, it spawn a task to generate the hash in background.

The time saved depends on the speed of user computer and its code execution.

Currently, there is no upper for the size of the file using to generate hash. If this file is small, the hash is generated quite fast however as it grows, it takes longer. For example, the program never exits if this command shavee -f /dev/zero is executed, because /dev/zero has no EOF. While this doesn't seem to be a safe usage of the program, it demonstrate a corner case.

A potential solution is to either hardcode a max size limit or pass it as an optional argument to the program.

In main.rs it looks like dataset passwords are being suffixed with "Aveesha". Is this a remnant from testing that should be removed?

https://github.com/ashuio/shavee/blob/af275d00cef4a55e4c0e67047278c20cee644466/src/main.rs#L28

This PR contains:

1. Implementation of unit tests for filehash.rs
   • Some of the tests depends on known locally generated files, they will run sequentially.
     • The test files will be generated by the unit test code,
     • The test files/folder will be deleted at the end of the unit test code.
2. filehash.rs is refactored to streamline the unit tests and error handling.

This PR includes:

• unit tests for filehash.rs functions.
  • tempfile crate was brought into scope only for unit tests [dev-dependencies]. It is used for generating temp folder in the system temp directory. This temp folder will be removed by OS as soon as its variable goes out of scope.
• removed pub from get_filehash_local() and get_filehash_http_sftp().
  • They are called only by get_filehash() which is already in the scope.
• refactored the error conversation to String from get_filehash_local() and get_filehash_http_sftp() to get_filehash()
  • This move makes it possible to implement unit tests for get_filehash_local() and get_filehash_http_sftp() that checks and verifies the complete error codes.
  • The code is easier to read and follow because now the Err to String conversation happens only once in each branch of get_filehash().
  • The unit test for get_filehash() only verifies the first 5 character of the error message because get_filehash() returns error in String and to avoid variation in error message implementations by the underlying OS.

This PR contains 3 changes:

1. Unit test for port_check() function in args.rs.
2. The fix for port 0 to be rejected as an invalid port.
3. Code clean up, merging matched arms and removing unnecessary brackets

This PR includes the implementation for #9 and #10.

1. Hash is now generated while user entering password.
2. Optional SIZE can be passed as CLI argument
3. Parse 'size' as 'Option'
4. Updated Plumping logic to pass variables to lib functions

This PR contains:

1. Fix for bug #7
   • NOTE: The associated unit test is still not able to test for this bug and possible regression can happen.
2. Refactored code to make main() only for entry and exit. This helps in integration test implementation.
3. Added Option<> support to Sargs and related codes.
4. Refactored key calculation into a separate function to eliminate repeated codes.

Hi,

It would by nice to test if key is already load before asking for a password.

Currently it give an error Error in mounting user ZFS dataset: Key load error: Key already loaded for

Thanks,

Current missing unit tests coverage as of PR #19 :

• [ ] Pam Module functions in shavee-pam::lib.rs
• [ ] All Yubikey related functions
• [ ] Simple (2~4 lines) functions in shavee-core::logic.rs

I'm using Shavee to unlock a ZFS dataset as part of my boot process, and thought I'd share how I'm doing it:

/etc/systemd/system/[email protected]

[Unit]
Description=Unlock ZFS Dataset %I with Shavee
DefaultDependencies=no
Before=systemd-user-sessions.service
Before=zfs-mount.service
After=zfs-import.target
After=systemd-vconsole-setup.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'set -eu;keystatus="$$(/sbin/zfs get -H -o value keystatus "%I")";[ "$$keystatus" = "unavailable" ] || exit 0;count=0;while [ $$count -lt 3 ];do  systemd-ask-password --id="zfs:%I"    "Enter passphrase for %I"|    shavee -y -s 1 -z "%I" && exit 0;  count=$$((count + 1));done;exit 1'
ExecStop=/bin/sh -c 'set -eu;keystatus="$$(/sbin/zfs get -H -o value keystatus "%I")";[ "$$keystatus" = "available" ] || exit 0;/sbin/zfs unload-key "%I"'

[Install]
WantedBy=zfs-mount.service

I'm using Slot 1 for HMAC challenges on my Yubikey, so you may need to alter the Shavee command if you're using a different slot

Then just enable the service for your encrypted pool, e.g. to unlock zroot/data you'd do systemctl enable zfs-shavee-unlock@zroot-data