-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add encryption option: per-user encrypted homdir #379
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 At logout, systemd unmounts the home directory and locks it? |
As requested by @rlaager - Thanks for the suggestions!
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:
***@***.***>
|
Thanks for the hints!
- Prevent two race conditions: between unlock (PAM) and mount (systemd) and between mount and the remaining login process - Minor cosmetic changes - Added the option to take a snapshot upon logout
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:
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. |
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.
|
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. |
I don't suppose that anything here helps, but FYI (merged): |
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...