11278 Encrypted ZFS filesystems should be mounted at boot where possible

Review Request #2025 — Created June 27, 2019 and updated Sept. 17, 2019, 9:09 a.m.

Information
Owner:	citrus
Repository:	illumos-gate
Branch:	master
Bugs:	11278
Depends On:
Commit:	e6d0b08...
Reviewers
Groups:	general
People:

Description

11278 Encrypted ZFS filesystems should be mounted at boot where possible

Testing Done

bloody# zfs list -o name,encryption,keylocation | grep -v off
NAME                              ENCRYPTION  KEYLOCATION
rpool/enc                        aes-256-ccm  file:///e.key
rpool/encb                       aes-256-ccm  file:///f.key
rpool/encp                       aes-256-ccm  prompt

bloody# ls -l /e.key /f.key
/f.key: No such file or directory
-rw-r--r--   1 root     root          32 Jun 26 12:34 /e.key

bloody# df -h | grep enc
bloody# zfs unload-keys -a

bloody# tail -f `svcs -L filesystem/local` &
bloody# svcadm restart filesystem/local
bloody# [ Jun 27 10:47:19 Stopping because service restarting. ]
[ Jun 27 10:47:19 Executing stop method (null). ]
[ Jun 27 10:47:19 Executing start method ("/lib/svc/method/fs-local"). ]
Loading encryption keys: rpool/enc Key load error: Failed to open key material file

WARNING: Failed to load keys for rpool/encb
Mounting encrypted filesystems
[ Jun 27 10:47:20 Method "start" exited with status 0. ]

bloody# df -h | grep enc
rpool/enc              289G   320K       213G     1%    /rpool/enc

bloody# zfs mount -l rpool/encp
Enter passphrase for 'rpool/encp':

bloody# df -h | grep enc
rpool/enc              289G   320K       213G     1%    /rpool/enc
rpool/encp             289G   320K       213G     1%    /rpool/encp

Issues

1
0
1
0
All Issues: 2

Description	From	Last Updated
Why not move this section to after line 89, and only do the zfs mout -va once (one could also ...	jbk	Sept. 13, 2019, 2:49 p.m.
I would explicitly look for 'file://' starting the value if that's all that we intend to mount here (and maybe ...	jbk	Sept. 13, 2019, 9:49 p.m.

Diff:

Revision 2 (+29)

Show changes

usr/src/cmd/svc/milestone/fs-local

A few things.

1.) Not sure if this is beyond the scope of your fix, but is there a way, or a place, to indicate "temporary key installed by loader, please trash immediately after use"?
2.) Is it possible that some methods for extracting keys (i.e. other URLs) require other services that occur after filesystem/local?
3.) Will this prevent/encourage/interact-at-all with any possibly future work for encrypted rpool/BEs (for distros that boot off an rpool)?

citrus Sept. 13, 2019, 9:54 p.m.

1) it's beyond the scope. I don't know of such a way or how the loader integration will look (tsoome has some ideas).
2) The only currently supported URL scheme is file so, for now, this dependency is enough.
3) There will probably be some rework required in the future. This is really just to allow for easier experimentation with encrypted datasets until more options are available.

Fix it!

usr/src/cmd/svc/milestone/fs-local (Diff revision 2)

Show all issues

Why not move this section to after line 89, and only do the zfs mout -va once (one could also look at the keystatus property to help)?

citrus Sept. 13, 2019, 9:54 p.m.

I did it this way so that I could make the second mount non-fatal on error. Open to suggestions.
The main point of this change is really to enable easier experimentation with encrypted datasets in the short term until better key management strategies are available.