Bug 718807

Summary: authconfig does not seem to setup properly ecryptfs for ssh connection
Product: [Fedora] Fedora Reporter: Piergiorgio Sartor <piergiorgio.sartor>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: jchadima, mattias.ellert, mgrepl, mhlavink, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: openssh-5.6p1-33.fc15.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-18 18:34:40 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Piergiorgio Sartor 2011-07-04 14:40:20 EDT
Description of problem:
After enabling "ecryptfs" with:

authconfig --enableecryptfs --update

or

authconfig --enableecryptfs --updateall

logging in using ssh does not result in "Private" mounted.

Note that "ecryptfs" is setup properly, so that "ecryptfs-mount-private" works. Furthermore the "ecryptfs" kernel module is loaded.

Version-Release number of selected component (if applicable):
authconfig-6.1.14-2.fc15.i686

How reproducible:
Always

Steps to Reproduce:
1.
Load "ecryptfs" kernel module
2.
Setup "ecryptfs" with "ecryptfs-setup-private"
3.
Logout and login using ssh

Actual results:
Folder "Private" is not mounted.

Expected results:
Folder "Private" should be mounted.

Additional info:
I guess this is a "pam" issue, since "/etc/pam.d/sshd" does not seems to bare anything with "/etc/pam.d/postlogin". Nevertheless, it could be an "ecryptfs" issue.
Comment 1 Tomas Mraz 2011-07-11 04:42:49 EDT
/etc/pam.d/sshd must include postlogin stacks in the similar way to /etc/pam.d/login or /etc/pam.d/gdm.
Comment 2 Fedora Update System 2011-07-14 09:12:26 EDT
openssh-5.6p1-33.fc15.1 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/openssh-5.6p1-33.fc15.1
Comment 3 Piergiorgio Sartor 2011-07-14 15:26:52 EDT
Hi all,

thanks for the quick response.

I just installed (from Koji) the new "openssh" package.

Still I've problem with mounting "Private" when logging in using "ssh".

The reason seems to be that the user does not belong to the group "ecryptfs" when logged in with "ssh".

From "root":

$ id testuser
uid=500(testuser) gid=500(testuser) groups=500(testuser),327(ecryptfs)

From "testuser" via "ssh"

$ id
uid=500(testuser) gid=0(root) groups=500(testuser)

And, of course, "ecryptfs-mount-private", from shell, does *not* work.

If, from this point, I re-login using "su - testuser", then "id" returns the same as for "root".

Nevertheless, "Private" is not mounted either, since "/etc/pam.d/su" seems not to bare anything with "postlogin" too.
"ecryptfs-mount-private" works fine, after "su".

So, summarizing, two issues:

1) User id is not as expected, after connecting with "ssh".
2) "authconfig" does not seem to setup "/etc/pam.d/su" properly.

Thanks again,

bye,

pg
Comment 4 Tomas Mraz 2011-07-14 17:12:05 EDT
Authconfig does not setup individual service files. So the 2) must be reported as a separate bug against coreutils package.

As for 1). What prints 'getent group ecryptfs'? However I am afraid that this problem might be related to the way openssh calls the pam functions.
Comment 5 Piergiorgio Sartor 2011-07-14 17:31:36 EDT
Hi Tomas,

(In reply to comment #4)
> Authconfig does not setup individual service files. So the 2) must be reported
> as a separate bug against coreutils package.

OK, I'll do that.

> As for 1). What prints 'getent group ecryptfs'? However I am afraid that this
> problem might be related to the way openssh calls the pam functions.

$ getent group ecryptfs
ecryptfs:x:327:testuser

Maybe, then also this issue should be re-assigned to "openssh"?

Thanks,

bye,

pg
Comment 6 Piergiorgio Sartor 2011-07-14 17:33:08 EDT
Ah! Silly me, this one was already re-assigned to "openssh".

bye,

pg
Comment 7 Tomas Mraz 2011-07-14 18:05:49 EDT
Hmm, that looks suspicious. I cannot reproduce the 1) here:

I added an user to some supplementary group and when logging in the user through sshd the group is assigned properly.
Comment 8 Tomas Mraz 2011-07-14 18:06:42 EDT
Can you try with other users and other supplementary groups whether it does not work for them either or is it a problem only with the testuser and ecryptfs group?
Comment 9 Fedora Update System 2011-07-14 21:21:39 EDT
Package openssh-5.6p1-33.fc15.1:
* 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 openssh-5.6p1-33.fc15.1'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/openssh-5.6p1-33.fc15.1
then log in and leave karma (feedback).
Comment 10 Piergiorgio Sartor 2011-07-15 03:18:28 EDT
Hi Tomas,

I created another user and added it to "ecryptfs" group.

Logging in using "ssh" does indeed work as expected, in respect of the "id" command. That is, the user id is reported correctly, belonging to the group "ecryptfs" too.

Until this point, the user did not have "Private" setup with ecryptfs.

If I setup it (ecryptfs-setup-private) then re-logging in with "ssh" results in the same issue as reported before, i.e. no gid "ecryptfs" and a funny gid=0(root). This last one is not supposed to be there.

Nevertheless, I've to apologise (I'll write 100 times: "I should not report issues late at night"), since I failed to report another phenomenon.

The first time I log in with "ssh", with "Private" setup, after the password is request, results in a lock up. There is no login happening, the whole thing is just waiting for Godot.

If I kill the client and re-run it, then I can login, but the funny gid=0 shows up.

If "Private" is not setup, everything is quick and fine.

Initially I was thinking that loading "ecryptfs.ko" was the problem, but now I think there's some strange interaction between "ssh", "pam" and "ecryptfs".

I checked /var/log/secure (I can paste it later, if you need), but I could not identify anything specific.

Could you please try to setup some dummy user, belonging to "ecryptfs" group, with "Private" setup, and login via "ssh"? If you can at least confirm my observation it would be a relief for me.

Finally, how about the status of this report?
Should be changed to something different that "ON_QA"?

Thanks a lot in advance,

bye,

pg
Comment 11 Tomas Mraz 2011-07-15 05:47:00 EDT
I think a new bug should be created for this issue. The original problem that pam_ecryptfs was not called at all in the PAM setup of sshd is now solved. The gid=0 is indeed very strange and even a security issue. So either this sshd/pam_ecryptfs problem should be either solved fast or the postlogin call from sshd should be reverted.

Please open the new bug against encryptfs and put into cc me and jchadima. 

Meanwhile until the issue is solved Jan, please, do not push the openssh update in F15 to stable!
Comment 12 Michal Hlavinka 2011-07-15 07:44:35 EDT
(In reply to comment #11)
> Meanwhile until the issue is solved Jan, please, do not push the openssh update
> in F15 to stable!

I second that, in fact I'd even recommend "unpush" until it's solved
Comment 13 Jan F. Chadima 2011-07-18 01:04:01 EDT
Unpushed, please let me know when repush.
Comment 14 Fedora Update System 2011-07-18 18:34:34 EDT
openssh-5.6p1-33.fc15.1 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Piergiorgio Sartor 2011-08-13 05:16:22 EDT
Hi all,

the latest ecryptfs-utils (from 87-7 on) seems to fix this one, so I guess the bug can be closed, if openssh supports the automount of ~/Private.

Thanks,

bye,

pg