pam_fscrypt: eliminate unnecessary options and improve documentation

[ebiggers]

• Make pam_fscrypt decide automatically whether dropping caches is needed, so that the "drop_caches" option is no longer needed.
• Make pam_fscrypt lock directories by default, so that the "lock_policies" option is no longer needed. As there is a chance that a small number of users might want the previous default behavior of unlock-only, add an option "unlock_only" to get that behavior.
• Fix some things in the README related to pam_fscrypt.

[josephlr]

This looks really good. Thanks for simplifying things!

One question, if we're already changing the functionality of the PAM module, do we even need an unlock_only flag? Personally, I don't really see the need for such a flag. Looking at #25 I didn't gave a rationale for why we shouldn't always relock a directory.

I think originally we were considering the case where two users shared a directory and it was protected by both their login passphrases. But I don't think that should be an issue now. With V2 policies, both users can provision and deprovision the same fscrypt key without any issues.

So unless there's a compelling reason to keep the old functionality, I say we just get rid of it.

[ebiggers]

This looks really good. Thanks for simplifying things!

One question, if we're already changing the functionality of the PAM module, do we even need an unlock_only flag? Personally, I don't really see the need for such a flag. Looking at #25 I didn't gave a rationale for why we shouldn't always relock a directory.

I think originally we were considering the case where two users shared a directory and it was protected by both their login passphrases. But I don't think that should be an issue now. With V2 policies, both users can provision and deprovision the same fscrypt key without any issues.

So unless there's a compelling reason to keep the old functionality, I say we just get rid of it.

I intended the unlock_only option as an "escape hatch" in case anyone really wants the old default behavior. There might be some edge cases where someone wouldn't want pam_fscrypt to lock their directories. For example, someone might have a directory with a login protector and expect to be able to manually unlock it, then have it stay unlocked regardless of any log-in and log-out from that user. For v2 encryption policies, that will work if root does the initial unlock, but not if the initial unlock is done as that user (e.g. in a shell in which root has run sudo $user) -- since there is no reference counting for how many times each user has added the key.

It's unlikely though, and v2 encryption policies made things work better. So I think you're right that for simplicity we just shouldn't add the option, unless someone asks for it.

[ebiggers]

Updated to not add the unlock_only option.

[plumbeo]

Hello, I'm sorry if I'm late but I got bitten by the new behaviour only now that I upgraded to the latest Ubuntu LTS release.

My use case is quite simple, I'm using fscrypt on a machine that's partially headless and now that every directory gets locked after I logout from my SSH session I can't use screen/tmux for long running processes, nor I can run VMs.

Is having back the option to not lock everything at logout still possible, or is there any alternative to prevent locking when screen/tmux are running?

Thanks.