add encryption option: per-user encrypted homdir

[christophhagemann]

I am no developer, just a somewhat experienced user. I tried my very best to not do something stupid, but I don't know if I succeeded. It works here (TM). Feel free to change anything.

Please note: I'm on debian/testing, not on bullseye. Should make no difference...

[rlaager]

I've made a first pass through this. Most of this is minor nitpicking. I haven't had a chance to actually walk through the steps yet.

[rlaager]

Am I understanding the theory of operation correctly here? When you login, PAM passes your password to the unlock script. The unlock script does the zfs load-key. Then the system unit mounts your home directory?

At logout, systemd unmounts the home directory and locks it?

[christophhagemann]

Am Montag, dem 30.01.2023 um 13:51 -0800 schrieb Richard Laager:

Am I understanding the theory of operation correctly here? When you login, PAM passes your password to the unlock script. The unlock script does the zfs load-key. Then the system unit mounts your home directory? At logout, systemd unmounts the home directory and locks it?

Almost. PAM runs the unlock script on every login. On subsequent logins the script does nothing. The systemd mount script on the other hand is only run on first login and last logout to avoid errors when other sessions are still running. One corner case is sudo. Systemd seems to ignore sudo: no user session is started when using sudo -u, so sudo -u <youruser> -i ends up without mounted home directory. I don't think this is a common use case except for root. This is why I chose not to support /root/ encryption.

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ghost]

I don't mean to pour cold water on this, just my two cents.

I think that any customization procedures that can be done post-installation -- any that does not involve repartitioning the disks -- should be done post-installation and documented elsewhere, like a blog or a wiki. The guide here should only be a starting point.

The installation guides maintained by myself previously suffered from feature-creep, I added Secure Boot, encrypted boot pool, SSH remote unlock, among others. The main disadvantages are the following:

• The procedures are not specific to the distro, and could be reused if it's posted on a wiki instead, such as Arch Linux wiki.
• Whenever the instructions need update, maintainers at openzfs/openzfs-docs must be involved, which increases their workload. In a wiki, they can be updated easily by a volunteer.
• The burden of testing every possible combination of configuration documented in the guide are shouldered by us, which is quite time-consuming.
• The extra options make the guide longer and more difficult to follow.

Therefore I moved the instructions to Arch Linux wiki, Alpine wiki, Fedora wiki and NixOS wiki respectively and dropped them from this repo. We now benefit from the oversight of volunteers there, an easier-to-follow installation guide, and less maintenance work. In particular, the NixOS Root on ZFS guide only requires 8 minutes(!) to follow for a multi-disk encrypted installation, excluding time used for downloading live media.

[christophhagemann]

I think that any customization procedures that can be done post- installation -- any that does not involve repartitioning the disks -- should be done post-installation and documented elsewhere, like a blog or a wiki. The guide here should only be a starting point.

I'm just a user. For me it would have been helpful to find this info in one place. It's not strictly post-install IMHO.

 * The procedures are not specific to the distro

Good point. May I suggest to move it to a separate page below "Getting started" - "Making use zfs' features" or similar and linking there from the distro-specific pages?

 * Whenever the instructions need update, maintainers at openzfs/openzfs-docs must be involved, which increases their workload.  * The burden of testing every possible combination of configuration documented in the guide are shouldered by us, which is quite time- consuming.

I'd volunteer to maintain this page.

 * The extra options make the guide longer and more difficult to follow.

Would be solved by creating a separate page. If there's consensus a separate distro-independent page would be desirable, I'd invest the time to rework my contribution and maintain the page afterwards.

[gmelikov]

Personally, I like universal small blocks of info. Have such pages on distros' wiki is good, but it requires to have contributors there.

So, LGTM to have dedicated pages here for these purposes, main thing to have appropriate navigation position for them. Maybe @rlaager or @ne9z have other opinions and may challenge me here.