Bug 722445 - ssh login to an account using ecryptfs Private pam mount results in dead lock and more
ssh login to an account using ecryptfs Private pam mount results in dead lock...
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils (Show other bugs)
i686 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-07-15 07:17 EDT by Piergiorgio Sartor
Modified: 2011-08-03 18:53 EDT (History)
4 users (show)

See Also:
Fixed In Version: ecryptfs-utils-87-6.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-03 18:53:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2011-07-15 07:17:52 EDT
Description of problem:
For a background explanation, please see bug #718807 were some details are revealed.

I'm trying to access a remote PC, using ssh, were a test user as the Private folder encrypted with ecryptfs.
This is simply done using "ecryptfs-setup-private".

One issue seemed to be the pam configuration of "ssh".
Solved this one still it is not possible to access the user nor to mount Private from pam.

The first login attempt results in a dead lock, while user without Private setup log in instantly.
After that, other login attempts succeed, but the Private is not mounted, since the user is not recognised as member of "ecryptfs" gid, but gid=0(root) is assigned.

Version-Release number of selected component (if applicable):

How reproducible:
After upgrading to the openssh with pam fix, always.

Steps to Reproduce:
login using ssh with an user using ecryptfs Private folder
Actual results:
First time it hangs. After killing the ssh client and retrying it succeed, but with the side effects described in bug #718807 i.e. no Private mounted and user id reporting gid=0 and no gid ecryptfs

Expected results:
It should login and mount Private as encrypted file system.

Additional info:
Comment 1 Michal Hlavinka 2011-07-15 07:39:31 EDT
I know about this, it's because ecryptfs pam module uses ugly hacks, because we need to get password retrieved in authentication stage (included in user's keyring) to (survive till) create session stage. If we don't use those ugly hacks, keyring does not contain any data when we need them. Unfortunately, there is no known solution yet.
Comment 2 Tomas Mraz 2011-07-15 07:53:01 EDT
Well at least it should not make the user session to have gid==0 and no gid ecryptfs.

IMO this needs to be fixed in pam_ecryptfs at least partially. The module should not in any circumstance do the above - it should fail regularly if the authentication is done in other process than the session.
Comment 3 Jan F. Chadima 2011-07-19 03:35:43 EDT
This bug in ecryptfs may lead to security related issues. The gid 0 may give to the user undesired privilegies. Please resolve this bug ASAP.
Comment 4 Fedora Update System 2011-07-19 10:42:44 EDT
ecryptfs-utils-87-5.fc14 has been submitted as an update for Fedora 14.
Comment 5 Fedora Update System 2011-07-19 10:42:57 EDT
ecryptfs-utils-87-6.fc15 has been submitted as an update for Fedora 15.
Comment 6 Fedora Update System 2011-07-22 21:59:31 EDT
Package ecryptfs-utils-87-7.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ecryptfs-utils-87-7.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 7 Fedora Update System 2011-08-03 18:52:54 EDT
ecryptfs-utils-87-7.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2011-08-03 18:53:17 EDT
ecryptfs-utils-87-6.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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