Page MenuHomeFreeBSD

PAM module for loading ZFS keys on login

Authored by on Sep 5 2021, 1:41 PM.



This patch provides a PAM module that loads a user's authentication token as a ZFS key for a user-specific dataset on login. It also includes a patch to libzfs to allow a key to be provided directly in a key location, without the need to use a file.

This is intended to be used to allow users to have an encrypted ZFS home directory that is usually unmounted, but which has its keys loaded when the user logs in.

Test Plan

This was tested on a live system, with cases including excluded users, incorrect passwords, and correct passwords. It has also been converted to a test program and evaluated that way.

Diff Detail

rG FreeBSD src repository
Lint Skipped
Unit Tests Skipped

Event Timeline

delphij requested changes to this revision.Sep 6 2021, 12:27 AM

This proposed module have a lot of behavior that is very different from the Oracle and the OpenZFS implementation and since we are naming it the same way I don't think it's a good idea to diverge from the other implementations, especially the most commonly used parameters like homes= and the lack of mounting of the datasets.

Also note that this implementation is using libzfs instead of libzfs_core, and I think the latter is the preferred way for new code.

(The upstream OpenZFS PAM module was BSD licensed, by the way, is there any reason not to use it as a starting point, by the way?)


Loading ZFS key material would require either be root, or have delegated access for load-key. Is there any reason not to mount the dataset after a successful authentication now that the key is already loaded (if successful)?


This is a very strange choice. Normally hostname is configured as the FQDN and therefore it's unlikely to be a pool name.

Also note that this is different from both Oracle and OpenZFS's contributed version of pam_zfs_key, which is using the dataset prefix instead of the path (there isn't an obvious reason to avoid using a dataset prefix, as the dataset already knows where to mount and have all required information one would need for mounting).


[OPTIONAL] Can we just append username after the existing prefix instead of allowing it in arbitrary location(s)?


Please refactor the code to use openpam_get_option() instead of rolling your own.


Please replace this with openpam_get_option().


Please replace this with strdup() and check return.


location is not sensitive data, why is this necessary? (also note that this memset is likely to be optimized away anyways).


Please replace this with strdup() and check return.

This revision now requires changes to proceed.Sep 6 2021, 12:27 AM

Abandoning, due to the existence of the upstream module in cddl