Bug 627260
Summary: | pam_ecryptfs incompatible with network login | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> |
Component: | ecryptfs-utils | Assignee: | Michal Hlavinka <mhlavink> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 13 | CC: | esandeen, karsten, kevin, mhlavink, piergiorgio.sartor |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-28 13:59:18 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Woodhouse
2010-08-25 13:51:44 UTC
Aha, I made it work: auth required pam_env.so auth [success=2 new_authtok_reqd=2 default=ignore] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth [success=ok new_authtok_reqd=ok default=die] pam_winbind.so cached_login use_first_pass auth required pam_ecryptfs.so unwrap auth required pam_permit.so However, this still isn't going to work if the user logs in using their Windows password and it's been changed so it no longer matches the password used to wrap the mount key. We should be prompting the user *again* in that case, shouldn't we? And then perhaps automatically re-wrapping the passphrase. first to be clear, what problem are you exactly trying to solve? just note: using network authentication seems like you are (maybe) trying to encrypt home directories from network filesystem, but ecryptfs does not work on those fs reliably/at all because they use too much stack and there is not enough stack left for ecryptfs. See https://bugs.launchpad.net/ecryptfs/+bug/277578 what was your original pam configuration (without ecryptfs)? Was it generated by authconfig? Btw, there is authconfig bug #86152 for ecryptfs support. Example, how to set up pam configuration for fedora (without winbind) can be found in bug #479727 comment #4 > Can the key setup be done in the setcred or open_session function instead? > Or has PAM_AUTHTOK been cleared by the time those run? I don't remember exactly if we tried setcred, but open_session is too late in the process and can't be used, because it's no longer possible to obtain password > However, this still isn't going to work if the user logs in using their Windows password and it's been changed so it no longer matches the password used to wrap the mount key. We should be prompting the user *again* in that case, shouldn't we? And then perhaps automatically re-wrapping the passphrase. well, that would be ideal case but right now I don't know if it's even possible to affect pam stack to ask user again for "old" passphrase not even thinking about the need changing the prompt to "add your old password" more probably this will need some extra service for windows machine that will rewrap the key when user change his password from windows box authconfig bug is bug #486152 In reply to comment #1, about the password change. This seems to be a common problem among the network authentication scheme, also with different OSes. I suspect, the only reasonable solution would be to have the certificate handled also by the authentication server itself. In this case, there will be always consistency between user passwords and certificates. Of course, pam (or whatever) could ask for the old password, but it could be the user changed it (on different PCs) already several times, making difficult to remember what it was. I would like to propose an RFE for all related network authentication schemes in order to support, if not already, certificates management. How does this sound? bye, pg This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |