Bug 627260 - pam_ecryptfs incompatible with network login
pam_ecryptfs incompatible with network login
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-25 09:51 EDT by David Woodhouse
Modified: 2011-06-28 09:59 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 09:59:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2010-08-25 09:51:44 EDT
I can't find a way to make pam_ecryptfs work with a PAM stack that allows *either* pam_unix or pam_winbind (or any other external) authentication.

If you do something like this:

auth        required	  pam_env.so
auth        required	  pam_ecryptfs.so unwrap
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_winbind.so cached_login use_first_pass
auth        required	  pam_deny.so

... then the password isn't even set by the time pam_ecryptfs.so is invoked, so it does nothing. And you can't put the pam_ecryptfs modules *after* the 'sufficient' pam_unix.so module either, because that means it'll never happen.

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?
Comment 1 David Woodhouse 2010-08-25 10:20:16 EDT
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.
Comment 2 Michal Hlavinka 2010-08-27 04:52:35 EDT
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
Comment 3 Michal Hlavinka 2010-08-27 04:54:51 EDT
authconfig bug is bug #486152
Comment 4 Piergiorgio Sartor 2011-01-19 11:27:30 EST
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
Comment 5 Bug Zapper 2011-06-01 06:27:28 EDT
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
Comment 6 Bug Zapper 2011-06-28 09:59:18 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.