Bug 282957 - 14.2-RC1 installer does not complete user account creation when ZFS encryption selected for user
Summary: 14.2-RC1 installer does not complete user account creation when ZFS encryptio...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 14.2-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-24 23:40 UTC by Mike Watkins
Modified: 2024-12-11 22:13 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Watkins 2024-11-24 23:40:11 UTC
14.2-RC1 installer does not complete user account creation when ZFS encryption has been selected for user via the install utility.

Steps to reproduce:

1. New installation on hardware, ZFS file system, within the installer, choose an encrypted home directory. /home/username is created, owned by root:wheel, and empty. Defaults otherwise selected.

2. Re-install, DO NOT choose an encrypted home directory in the installer, /home/username is created, properly owned by username:username and has the appropriate template .dotfiles and contents within.

3. Re-install, per #1, as expected, /home/username is owned by root:wheel and empty.
Comment 1 Colin Percival freebsd_committer freebsd_triage 2024-11-24 23:48:53 UTC
Does the user name have a ':' or '.' character in it?

Can you confirm whether `mount` shows the ZFS filesystem being mounted and (if not) whether `zfs list` shows it as existing?
Comment 2 Mike Watkins 2024-11-25 00:00:32 UTC
The username is simply "mw", and can confirm the mountpoint exists.

# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot               3.57G   454G    96K  /zroot
zroot/ROOT          2.65G   454G    96K  none
zroot/ROOT/default  2.65G   454G  2.65G  /
zroot/home           428K   454G   200K  /home
zroot/home/mw        228K   454G   228K  /home/mw
zroot/tmp            104K   454G   104K  /tmp
zroot/usr            937M   454G    96K  /usr
zroot/usr/ports      937M   454G   937M  /usr/ports
zroot/usr/src         96K   454G    96K  /usr/src
zroot/var            788K   454G    96K  /var
zroot/var/audit       96K   454G    96K  /var/audit
zroot/var/crash       96K   454G    96K  /var/crash
zroot/var/log        236K   454G   236K  /var/log
zroot/var/mail       168K   454G   168K  /var/mail
zroot/var/tmp         96K   454G    96K  /var/tmp

The ZFS filesystem mountpoint exists and is reported by mount as well.

# mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
/dev/gpt/efiboot0 on /boot/efi (msdosfs, local)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/home on /home (zfs, local, noatime, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
Comment 3 Colin Percival freebsd_committer freebsd_triage 2024-11-25 00:10:10 UTC
> The ZFS filesystem mountpoint exists and is reported by mount as well.

I don't see /home/mw in the list from mount(8).  Am I missing something?
Comment 4 Mike Watkins 2024-11-25 00:26:50 UTC
Damn, I swear I saw it, but when I first looked, I did not see it either. Unfortunately my terminal history disappeared as I had to reboot the target machine and my window lockedup.

Perhaps I misread /var/mail but doubt that. Can't reproduce at the moment.

At this point, `mount` does not show /home/mw.
Comment 5 Colin Percival freebsd_committer freebsd_triage 2024-11-25 00:36:37 UTC
If you run `zfs mount /home/mw` does the home directory show up with the right permissions and contents?
Comment 6 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2024-11-25 00:37:23 UTC
I assume this is after the post-install reboot.  The ZFS dataset exists but is not mounted because you have not loaded the passphrase.  You'll need to configure `pam_zfs_key` to do it automatically on login.  Unfortunately it doesn't work with sshd because the OpenSSH developers have intentionally broken PAM integration, but for console logins you can append the following to /etc/pam.d/system:

auth	optional	pam_zfs_key.so	try_first_pass homes=zroot/home
session	optional	pam_zfs_key.so	homes=zroot/home
Comment 7 Mike Watkins 2024-11-25 01:00:01 UTC
Colin:

zfs mount zroot/home/mw
cannot mount 'zroot/home/mw': encryption key not loaded

I've never used home directory encryption on FreeBSD; wanted to test this for 14.2-RC1.

Dag-Erling: I've been wondering about the key; all this time, I've been logging into the system from the console all this time and have not been prompted for the passkey, which sounds like an installer configuration problem, perhaps too.

Is this documented? Again its new to me. I see in /etc/rc.d/zfskeys a reference to zfskeys_enable (tried that, nothing).
Comment 8 Colin Percival freebsd_committer freebsd_triage 2024-11-25 01:50:54 UTC
I think Dag-Erling may have been a bit quick in closing this... speaking as release engineer, even if the *code* is doing what is intended, it sounds like we need to better document how this works if a long-time FreeBSD user is getting tripped up by this.
Comment 9 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2024-11-25 01:51:59 UTC
You need to run `zfs load-key` before mounting.
Comment 10 John Grafton 2024-11-30 17:17:39 UTC
Documenting pam_zfs_key was part of the plan when I originally added the zfs encryption option to adduser.  Unfortunately, I got stuck on where to document it and life quickly got busy and I forgot all about it.

adduser.8 makes the most sense, I think, and add commented out lines to /etc/pam.d/system with the necessary pam_zfs_key references, similar to the pam_krb5 lines.

Another option is to add a message to adduser itself warning the user, "If you enable encryption, more configuration will be needed to enable seamless logins."

The option that's probably the most user friendly but hacky is to make the changes to /etc/pam.d/system from within adduser.
Comment 11 Colin Percival freebsd_committer freebsd_triage 2024-11-30 17:54:58 UTC
I don't think we want adduser making changes to system configuration files; adding a new user shouldn't affect anything except that user.

Aside from that I'm inclined to go with all of the above: Add documentation to adduser.8, add commented out lines to /etc/pam.d/system, and add a warning to adduser.  Can you put together a patch in the next month so we can have this in 13.5?
Comment 12 John Grafton 2024-11-30 19:01:17 UTC
Yes, I'll have the patch ready to go in time for 13.5.
Comment 13 Graham Perrin 2024-11-30 19:40:16 UTC
Thanks, everyone. 

base 516009ce8d380c8299a1d1115b24251c0925562b was on releng/14.1 but not on any 13 branch, if that's relevant. 

<https://github.com/freebsd/freebsd-src/commit/516009ce8d380c8299a1d1115b24251c0925562b> (2024-04-29)

% rg --sort path --count adduser /usr/doc/website/content/en/releases | grep -e 13 -e 14
/usr/doc/website/content/en/releases/14.1R/relnotes.adoc:1
% 

----

For <https://www.freebsd.org/releases/14.1R/errata/#open-issues> and 
for <https://www.freebsd.org/releases/14.2R/errata/#open-issues>, a bullet point, please:

- For home directories that use the OpenZFS encryption feature of adduser(8): documentation on use of encryption keys is not yet complete.


– or words to that effect. The point should refer to <https://bugs.freebsd.org/282957>, so that readers can track and (ideally) understand the issue.
Comment 14 John Grafton 2024-12-08 22:21:22 UTC
Patch submitted for review: https://reviews.freebsd.org/D47996
Comment 15 Edward.Sanford.Sutton, III 2024-12-11 22:13:29 UTC
  Instead of just documenting it as a commented line, can we:
  1. add an option during install before user creation that will setup home directory encryption to work at login? That option can explain if logins will be limited to local (non ssh) terminals if that is a known constraint of choosing it.
  2. modify adduser to not prompt for it if the current setup would not function with a message that it is skipped with why or a reference to further documentation (silence here may make more sense if it follows an installer option but output would be good when ran separately) or allow the prompt but explain it will not likely function as expected until changes are made appropriately.
  Documenting it should be easier for users to eventually make the system work as expected but the installer should guide the users into creating a working configuration of a system; settings that are known to not work should be blocked/removed and if it has any known major limitations then the user should be informed.