pam_ecryptfs doesn't live well with pam_keyinit
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| eCryptfs |
Fix Released
|
Medium
|
Dustin Kirkland | ||
Bug Description
Linux PAM package contains pam_keyinit module which can manage (grant and revoke) session keys for a user.
pam_ecryptfs doesn't deal with that well.
For example pam_ecryptfs reports: "Error attempting to add filename encryption key to user session keyring; rc = [1]". where 1 AFAIK means that the key already exists. That's because pam_keyinit added it already.
From looking into code:
A) ecryptfs_
B) ecryptfs_
If B) returns non zero then it is treated as an error but "1" means key
already exits. Maybe 1 should also be treated as "ok" ?
Anyway with pam_keyinit I wasn't able to setup ecryptfs to correctly encrypt $HOME.
Mine keyinit usage is:
session optional pam_keyinit.so revoke debug (system-auth)
or
session optional pam_keyinit.so force revoke (sshd)
as first session module.
| Changed in ecryptfs: | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
| Dustin Kirkland (kirkland) wrote | #1 |
| Dustin Kirkland (kirkland) wrote | #2 |
| Changed in ecryptfs: | |
| assignee: | nobody → Dustin Kirkland (kirkland) |
| status: | Triaged → In Progress |
| Dustin Kirkland (kirkland) wrote | #3 |
| Changed in ecryptfs: | |
| status: | In Progress → Fix Committed |
| Changed in ecryptfs: | |
| status: | Fix Committed → Fix Released |
Howdy! Thanks for this bug report.
I think you're right about handling (b)'s exit code better. If it's already there, then the end desired effect is what you wanted.
I'm marking Triaged/Medium.