Bug 495143 - Private directory does mount after login but files are still encrypted
Private directory does mount after login but files are still encrypted
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-09 18:00 EDT by Sachin Garg
Modified: 2009-08-11 07:57 EDT (History)
5 users (show)

See Also:
Fixed In Version: ecryptfs-utils-78-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-11 07:57:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
system-auth file (1.03 KB, text/plain)
2009-04-09 18:01 EDT, Sachin Garg
no flags Details

  None (edit)
Description Sachin Garg 2009-04-09 18:00:01 EDT
Description of problem:

Private directory does mount after login but files are still encrypted. I have made the changes in the /etc/pam.d/system-auth. As mentioned in the bug.

Output of the keyctl just after login.

[sachin@localhost Private]$ keyctl list @u 
1 key in keyring:
992114892: --alswrv   501     0 user: d246ab35943e5a6e

[sachin@localhost Private]$ ls
ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4iZcPMbjOw5xXKNgDsdBOok--
ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4WgTVcwgjyefq9w8Paq6Ivk--

I perform following action to correct this problem

sudo umount Private/
[sachin@localhost ~]$ keyctl clear @u
[sachin@localhost ~]$ ecryptfs-mount-private
Enter your login passphrase: 




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

ecryptfs-utils-73-1.fc11.i586

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Sachin Garg 2009-04-09 18:01:04 EDT
Created attachment 339007 [details]
system-auth file
Comment 2 Michal Hlavinka 2009-04-10 07:17:46 EDT
Hi,

could you add output of 'mount' after login and after 'ecryptfs-mount-private', also output of 'keyctl list @u' after ecryptfs-mount-private, and lines from /var/log/messages and /var/log/secure produced by ecryptfs.

Did you change password recently (after you used ecryptfs-setup-private) ?

Did you use only ecryptfs-setup-private and modified system-auth or did you do also anything else to set this up?

Are these files completely encrypted or only their names are encrypted?

Thanks,
Michal
Comment 3 Sachin Garg 2009-04-10 11:39:26 EDT
could you add output of 'mount' after login and after 'ecryptfs-mount-private',
also output of 'keyctl list @u' after ecryptfs-mount-private, and lines from
/var/log/messages and /var/log/secure produced by ecryptfs.

Just after login

[sachin@localhost ~]$ mount
/dev/sda6 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/home/sachin/.Private on /home/sachin/Private type ecryptfs (ecryptfs_sig=d246ab35943e5a6e,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
gvfs-fuse-daemon on /home/sachin/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=sachin)

After ecryptfs-mount-private

[sachin@localhost ~]$ mount
/dev/sda6 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /home/sachin/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=sachin)
/home/sachin/.Private on /home/sachin/Private type ecryptfs (ecryptfs_sig=d246ab35943e5a6e,ecryptfs_fnek_sig=b88c043367b3bd0d,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

[sachin@localhost ~]$ keyctl list @u
2 keys in keyring:
665315082: --alswrv   501   501 user: b88c043367b3bd0d
540237850: --alswrv   501   501 user: d246ab35943e5a6e
[sachin@localhost ~]$ 



Did you change password recently (after you used ecryptfs-setup-private) ?

No

Did you use only ecryptfs-setup-private and modified system-auth or did you do
also anything else to set this up?

Just ecryptfs-setup-private and modified system-auth

Are these files completely encrypted or only their names are encrypted?

Yes the files are completely encrypted.
Comment 4 Sachin Garg 2009-04-10 11:42:23 EDT
/var/log/messages

Apr 10 10:14:57 localhost pam: gdm[2661]: pam_sm_authenticate: Called
Apr 10 10:14:57 localhost pam: gdm[2661]: pam_sm_authenticate: username = [sachin]
Apr 10 10:14:57 localhost pam: gdm[2661]: Warning: Using default salt value (undefined in ~/.ecryptfsrc)
Apr 10 10:14:59 localhost pam: gdm[2661]: Mount of private directory return code [0]


/var/log/secure

Apr 10 10:14:59 localhost pam: gdm[2661]: pam_unix(gdm:session): session opened for user sachin by (uid=0)
Apr 10 10:16:38 localhost sudo:   sachin : TTY=pts/0 ; PWD=/home/sachin ; USER=root ; COMMAND=/bin/umount Private/
Comment 5 Michal Hlavinka 2009-04-10 13:02:29 EDT
Please check that ~/.ecryptfs/Private.sig has 2 lines
d246ab35943e5a6e
b88c043367b3bd0d

If one of them is missing, please try to add the missing one to that file and retest. Thanks
Comment 6 Sachin Garg 2009-04-10 14:05:43 EDT
Both the lines are present

[sachin@localhost ~]$ cat ~/.ecryptfs/Private.sig
d246ab35943e5a6e
b88c043367b3bd0d
Comment 7 Sachin Garg 2009-04-10 23:17:17 EDT
I am sorry but this answer to following question is incorrect

-----------
Are these files completely encrypted or only their names are encrypted?

Yes the files are completely encrypted.  
----------

Contents are not encrypted after the login. But files names are...
Comment 8 Michal Hlavinka 2009-04-14 11:52:41 EDT
I'm looking at this bug but I can't find where is the problem, because it works for me and everything seems correct. Would you like to test modified (with additional debug output) version of ecryptfs-utils?
Comment 9 Sachin Garg 2009-04-14 12:04:00 EDT
sure. Can you please provide me steps how to do it ?
Comment 10 Michal Hlavinka 2009-04-15 06:42:55 EDT
I've prepared that packages, but I've also somehow triggered this bug and it's reproducible for me now. I'll test it myself.
Comment 11 Michal Hlavinka 2009-05-15 04:48:14 EDT
This should be fixed in ecryptfs-utils-75

Can you confirm this?
because of devel freeze, you need packages from koji:
http://koji.fedoraproject.org/koji/buildinfo?buildID=100907

i586 package:
http://kojipkgs.fedoraproject.org/packages/ecryptfs-utils/75/1.fc11/i586/ecryptfs-utils-75-1.fc11.i586.rpm
Comment 12 Sachin Garg 2009-05-20 12:34:36 EDT
No this does not work. Still the file name remains encrypted. They get decrypted only after second attempt.
Comment 13 Michal Hlavinka 2009-05-21 12:15:46 EDT
that's odd, it seems there is more than just one problem...

1)reboot your system

2)log in as root first

3)add your user to ecryptfs group:

usermod -G ecryptfs your_login

4)load ecryptfs kernel module:

modprobe ecryptfs

5)switch selinux to permissive mode

setenforce 0

6)now try to log as the user and check if it works

if this works, please try to repeat this, but skip step number 5

You can switch selinux back to enforcing mode with:
setenforce 1
or by rebooting.

thanks
Comment 14 Sachin Garg 2009-05-21 12:39:48 EDT
Doing the step 3 and Step 4 helped
Now I am able to mount the Private directory in one go.. 

PS: I am not using the SE linux

Thanks fr=or the hard work ..
Comment 15 Michal Hlavinka 2009-05-21 13:12:20 EDT
ok, thanks for testing, I know where is the problem now
Comment 16 Michal Hlavinka 2009-05-22 06:57:34 EDT
I hope I've fixed this issue. Can you confirm this?

all packages:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1370150

i586 package:
http://koji.fedoraproject.org/koji/getfile?taskID=1370156&name=ecryptfs-utils-75-2.fc11.i586.rpm
Comment 17 Sachin Garg 2009-05-22 16:56:05 EDT
Private directory does not mount automatically after the reboot. system-auth is as same as in the comment 1 of this bug.

But if I do
modprobe ecryptfs
ecryptfs-mount-private

everything works greats.


Thanks for looking into it
Comment 18 Michal Hlavinka 2009-05-25 03:37:51 EDT
so with latest test package, it doesn't mount? Are there any related messages in /var/log/messages or /var/log/secure?

The latest package should load kernel module itself.
Comment 19 Sachin Garg 2009-05-26 11:54:26 EDT
so with latest test package, it doesn't mount?

yes

Are there any related messages in /var/log/messages or /var/log/secure?

No

The latest package should load kernel module itself.  

Yes it does

[sachin@localhost ~]$ lsmod |grep ecryptfs
[sachin@localhost ~]$ ecryptfs-mount-private
Enter your login passphrase: 

Inserted auth tok with sig [d246ab35943e5a6e] into the user session keyring
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
[sachin@localhost ~]$ lsmod |grep ecryptfs
ecryptfs               83620  1

[sachin@localhost ~]$ cd Private/
[sachin@localhost Private]$ ls
ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4iZcPMbjOw5xXKNgDsdBOok--
ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4WgTVcwgjyefq9w8Paq6Ivk--
Comment 20 Michal Hlavinka 2009-05-27 03:11:22 EDT
File names are not decrypted, because file name encryption is not used.

FNE is not used, because helper doesn't know if your kernel supports it.

It doesn't know if it's supported because /sys/fs/ecryptfs/version is missing.

...and it's missing because kernel module is not loaded.

Kernel module is always loaded if you use mount -t some_filesystem ..., but this is too late, because we need to have all parameters prepared for mount.

Ecryptfs helpers check ecryptfs kernel version and tries to load kernel module with new check if it fails. Unfortunately, not privileged user can't load kernel modules.

Now, kernel module can be loaded only from pam ecryptfs module. So if you use login auto-mount, file names should be decrypted.

I'll try to rewrite this to be independent on kernel module presence, but it'll take some time...
Comment 21 Sachin Garg 2009-05-27 14:03:08 EDT
Thanks for the explanation !!

Do I need change any configure so that the private directory mount itself at the time of login.

I am using the sytem-auth as in comment 1
Comment 22 Michal Hlavinka 2009-05-28 03:59:32 EDT
ecryptfs-setup-private, system-auth and membership in ecryptfs group should be enough to use login auto-mount 

(there is another problem in selinux which is fixed in most recent selinux-policy-targeted and ecryptfs-utils, but it's not necessary for you since you are not using selinux)
Comment 23 Sachin Garg 2009-06-02 17:14:43 EDT
I am sorry . But are you waiting on me to provide you information ?
Comment 24 Michal Hlavinka 2009-06-03 03:08:30 EDT
I'd like to know if pam auto-mount is working now (used ecryptfs-setup-private, system-auth and membership in ecryptfs group should be enough to use login auto-mount)

You need to (In reply to comment #19)
> ... 
> The latest package should load kernel module itself.  
> 
> Yes it does
> 
> [sachin@localhost ~]$ lsmod |grep ecryptfs
> [sachin@localhost ~]$ ecryptfs-mount-private
> ....

loading module itself was related only to pam module not to ecryptfs-mount-private (all mount helpers load kernel module - in fact system mount call loads them], but too late. This is the reason you've got:

> [sachin@localhost ~]$ lsmod |grep ecryptfs
> ecryptfs               83620  1
> 
> [sachin@localhost ~]$ cd Private/
> [sachin@localhost Private]$ ls
> ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4iZcPMbjOw5xXKNgDsdBOok--
> ECRYPTFS_FNEK_ENCRYPTED.FWasX-EnNvCx1ERRuiGMxgWGGqbfDj8EiBu4WgTVcwgjyefq9w8Paq6Ivk--

pam automount has enough privileges, so it should load module itself and file names should be decrypted (if you are not using selinux - for selinux you need updated selinux-policy-targeted)
Comment 25 Sachin Garg 2009-06-03 18:35:57 EDT
I'd like to know if pam auto-mount is working now (used ecryptfs-setup-private,
system-auth and membership in ecryptfs group should be enough to use login
auto-mount)

No. It is not working..
Comment 26 Michal Hlavinka 2009-06-04 05:30:17 EDT
> No. It is not working..  

that's bad, it should be working now... is it not working completely or file names are not decrypted? anything in logs: messages or secure?

I've tried it this (new) package:
http://koji.fedoraproject.org/koji/buildinfo?buildID=104801

i586:
http://kojipkgs.fedoraproject.org/packages/ecryptfs-utils/75/3.fc11/i586/ecryptfs-utils-75-3.fc11.i586.rpm

Could you check it?

what I did for testing :
su -
useradd testuser
usermod -G ecryptfs testuser
echo test | passwd --stdin testuser
curl https://bugzilla.redhat.com/attachment.cgi?id=339007 >/etc/pam.d/system-auth
modprobe ecryptfs
logout
#login as testuser with password test (not using 'su') 
ecryptfs-setup-private
ecryptfs-mount-private
mount #checked mount option contains ecryptfs_fnek_sig=
echo hello >~/Private/world.txt
ecryptfs-umount-private
logout
su -
modprobe -r ecryptfs
#login as testuser (not using 'su') 
ls Private/
# world.txt

this passed even with selinux in enforcing mode
Comment 27 Sachin Garg 2009-06-05 11:04:04 EDT
Michal,

Thanks a lot for working patiently with on this issue with me.

Looks the problem is when I do gnome login then the Private directory does not mounts at all.

But when I do a terminallogin Private directory mounts and file and contents are decrypted correctly.

Regards,
Sachin.
Comment 28 Bug Zapper 2009-06-09 09:34:49 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Michal Hlavinka 2009-06-18 10:18:00 EDT
I've tried this with kde and it works fine. I'll try it with gnome later. Do you use auto login or some other special functions?
Comment 30 Sachin Garg 2009-06-18 20:15:55 EDT
Do you use auto login ?
no
or some other special functions?  
no
Comment 31 Jason Elwell 2009-06-23 02:00:29 EDT
First, thanks for looking into this!  I am experiencing the exact same issue.  I would be happy to help if I can.  May be its helpful to note I did a preupgrade upgrade from 10 -> 11.  I /then/ installed ecryptfs.  Using Sachin's workaround, I too can decrypt file names, and again once mounted, the contents are unencrypted whether the names are or are not.  I had also just done a fresh install on another lappy running F11, and it too has issues.  The to machines are almost identically setup as far as packages.  Double clicking the link: "The application launcher "Access-Your-Private-Data.desktop has not been marked as trusted. ..."  I know I'm not a moron, because I set it up fine on Ubuntu.

One more note...I was able to look at the ecryptfs-mount-private script.  I was able to successfully run ecryptfs-insert-wrapped-passphrase-into-keyring manually.  I was also, then, able to run /sbin/mount.ecryptfs_private successfully.  I did that several times, so it seems like your binaries work perfectly.

$ ecryptfsd --version
ecryptfsd (ecryptfs-utils) 75

post ecryptfs-mount-private (non existant before)(still exists after Gnome logout):
$ mount
/home/jason/.Private on /home/jason/Private type ecryptfs (ecryptfs_sig=9899f8208bc3d795,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

$ cat /etc/selinux/config 
SELINUX=permissive
SELINUXTYPE=targeted

$ lsmod |grep ecrypt
ecryptfs               94912  1 

$ id
uid=500(jason) gid=500(jason) groups=484(ecryptfs),500(jason) context=unconfined_u:unconfined_r:unconfined_t:s0

$ cat ~/.ecryptfs/Private.sig
9899f8208bc3d795
1257c55460be237e

$ ls Private/
ECRYPTFS_FNEK_ENCRYPTED.FWYGJwJIM9sXTURm2AFzhDJ-pxheA8yAvN0c20a6RGlYCqxpw9SKZrVFFk--
<snip>

$ keyctl list @u
1 key in keyring:
815402133: --alswrv   500   500 user: 9899f8208bc3d795

$ ecryptfs-mount-private
Inserted auth tok with sig [9899f8208bc3d795] into the user session keyring
Comment 32 Jason Elwell 2009-06-23 02:19:09 EDT
I removed the >/dev/null 2>&1 from the script.  Though the drive mounts with encrytped file names (clear data), /sbin/mount.ecryptfs_private complains that keyctl_search: Required key not available

Hope this helps!
Comment 33 Jason Elwell 2009-06-23 02:34:45 EDT
Ok sorry for the triple post.  
Here's what really works without clearing the keys:
$ ecryptfs-insert-wrapped-passphrase-into-keyring
$ mount.ecryptfs_private 
-- fails with encrypted names
$ sudo umount Private
$ ecryptfs-insert-wrapped-passphrase-into-keyring
-- error message
$ /sbin/mount.ecryptfs_private
Everything works perfectly!!
Comment 34 Michal Hlavinka 2009-06-23 03:47:04 EDT
(In reply to comment #33)
> Ok sorry for the triple post.  
> Here's what really works without clearing the keys:
> $ ecryptfs-insert-wrapped-passphrase-into-keyring
> $ mount.ecryptfs_private 
> -- fails with encrypted names
> $ sudo umount Private
> $ ecryptfs-insert-wrapped-passphrase-into-keyring
> -- error message
> $ /sbin/mount.ecryptfs_private
> Everything works perfectly!!  

so you are not using login auto-mount, right?

If there is only one key in the keyring when mounting ecryptfs dir, file names won't be decrypted. "Only" problem is to find out when and why the second key is missing. I thought this is related only to pam module, if you have this problem without pam auto-mounting, it's new useful information.
Comment 35 Michal Hlavinka 2009-06-23 03:58:32 EDT
(In reply to comment #33)
> Ok sorry for the triple post.  
> Here's what really works without clearing the keys:
> $ ecryptfs-insert-wrapped-passphrase-into-keyring
> $ mount.ecryptfs_private 
> -- fails with encrypted names
> $ sudo umount Private
> $ ecryptfs-insert-wrapped-passphrase-into-keyring
> -- error message

what error message is it?

> $ /sbin/mount.ecryptfs_private
> Everything works perfectly!!
Comment 36 Michal Hlavinka 2009-06-23 04:18:46 EDT
and did you try this with f11's original version or version from comment #26 ? (for x86_64 packages use firts link)
Comment 37 Jason Elwell 2009-06-23 23:06:28 EDT
[jason@localhost ~]$ ecryptfs-insert-wrapped-passphrase-into-keyring
Passphrase: 
Inserted auth tok with sig [9899f8208bc3d795] into the user session keyring
[jason@localhost ~]$ /sbin/mount.ecryptfs_private 
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
[jason@localhost ~]$ sudo umount /home/jason/Private
[jason@localhost ~]$ ecryptfs-insert-wrapped-passphrase-into-keyring
Passphrase: 
Error: Unwrapping passphrase and inserting into the user session keyring failed [1]
Info: Check the system log for more information from libecryptfs
[jason@localhost ~]$ /sbin/mount.ecryptfs_private 
[jason@localhost ~]$ 


from /var/log/messages
Jun 23 22:47:37 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to add passphrase key to user session keyring; rc = [1]

nothing in /var/log/secure

I installed the original package.  I will uninstall and report back.
Comment 38 Jason Elwell 2009-06-23 23:16:24 EDT
I'm sorry but the Koji package didnt do the trick.  :(
Comment 39 Jason Elwell 2009-06-23 23:19:25 EDT
Argh...more triple posts...sorry...

from /var/log/messages running the script to mount twice:

Jun 23 23:14:28 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to add passphrase key to user session keyring; rc = [1]
Jun 23 23:14:31 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to add filename encryption key to user session keyring; rc = [1]
Jun 23 23:14:31 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to add passphrase key to user session keyring; rc = [1]
Comment 40 Michal Hlavinka 2009-06-24 03:19:13 EDT
Jason:
I've fixed the second error. I'm still not 100 % convinced that both problems are the same.

Jason:
Sachin:

I've built new packages. They contain some related fixes and additional debug messages. Could you please try them and report how they work and what error messages you get in log? Thanks

build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1432983

i586:
http://koji.fedoraproject.org/koji/getfile?taskID=1432987&name=ecryptfs-utils-75-4.fc11.i586.rpm

x86_64:
http://koji.fedoraproject.org/koji/getfile?taskID=1432985&name=ecryptfs-utils-75-4.fc11.x86_64.rpm
Comment 41 Sachin Garg 2009-06-24 12:08:26 EDT
I tried the new rpm from comment 40.

Following is the out come.

Private does not automount when I login from the gnome session.


When I try to do the console or ssh login to my box. Everything works fine  Private directory is mounted, filename and contents are unencrypted.


/var/log/messages
-----------------
Jun 24 09:15:20 DL03044 mount.ecryptfs_private: It seems FNEK is supported
Jun 24 09:15:20 DL03044 mount.ecryptfs_private: CHECK: FEKEK in keyring? : 126269642
Jun 24 09:15:20 DL03044 mount.ecryptfs_private: CHECK: FNEK in keyring? : 502885670
Jun 24 09:15:23 DL03044 umount.ecryptfs_private: It seems FNEK is supported
Jun 24 09:15:23 DL03044 umount.ecryptfs_private: CHECK: FEKEK in keyring? : 126269642
Jun 24 09:15:23 DL03044 umount.ecryptfs_private: CHECK: FNEK in keyring? : 502885670

/var/log/secure

Jun 24 09:15:17 DL03044 sshd[2165]: pam_sm_authenticate: Called
Jun 24 09:15:17 DL03044 sshd[2165]: pam_sm_authenticate: username = [sachin]
Jun 24 09:15:17 DL03044 sshd[2165]: Kernel module version : 375
Jun 24 09:15:18 DL03044 sshd[2180]: fnek insert called
Jun 24 09:15:19 DL03044 sshd[2180]: fekek insert called
Jun 24 09:15:20 DL03044 sshd[2165]: Accepted password for sachin from 127.0.0.1 port 51966 ssh2
Jun 24 09:15:20 DL03044 sshd[2165]: pam_unix(sshd:session): session opened for user sachin by (uid=0)
Jun 24 09:15:20 DL03044 sshd[2165]: Mount of private directory return code [0]
Jun 24 09:15:23 DL03044 sshd[2165]: pam_unix(sshd:session): session closed for user sachin
Jun 24 09:15:23 DL03044 sshd[2165]: Mount of private directory return code [0]
Comment 42 Jason Elwell 2009-06-24 22:46:32 EDT
Thank you for your persistence, Michal!  
Success!  I have a pretty icon that shows up in my Private folder.  When I log into Gnome, I only have to launch once.  I put in my password (each time I log in) and it works the first time.  This works for my 2 machines one is 64 bit, one 32 bit.  Could it be applicable that both were installed from live CDs?

I don't know what the expected outcome is but: 
No auto mount neither via ssh nor gdm login.  
I am prompted for my password once each time I log in.

/var/log/messages
Jun 24 22:14:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fnek insert called
Jun 24 22:14:37 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fekek insert called
Jun 24 22:14:39 localhost mount.ecryptfs_private: It seems FNEK is supported
Jun 24 22:14:39 localhost mount.ecryptfs_private: CHECK: FEKEK in keyring? : 683175303
Jun 24 22:14:39 localhost mount.ecryptfs_private: CHECK: FNEK in keyring? : 490809149

/var/log/secure
*nothing relevant*
Comment 43 Jason Elwell 2009-06-25 00:49:57 EDT
One last bit of info for tonight:
I checked my working Ubuntu machine.  On my Fedora machines, there is no call to pam_ecrpytfs.so.  I added the line:
session optional    pam_ecrpytfs.so unwrap
to both /etc/pam.d/login and /etc/pam.d/gdm-password (i /think/ those would be the corresponding "right" ones)

Now...I can see the dir trying to mount on login, but failing with:

/var/log/secure
Jun 25 00:29:55 localhost login: pam_unix(login:session): session opened for user jason by LOGIN(uid=0)
Jun 25 00:29:55 localhost login: Mount of private directory return code [256]
Jun 25 00:29:55 localhost login: LOGIN ON tty3 BY jason
Jun 25 00:32:37 localhost login: pam_unix(login:session): session closed for user jason
Jun 25 00:32:37 localhost login: Mount of private directory return code [256]
Jun 25 00:32:57 localhost pam: gdm-password[4771]: pam_unix(gdm-password:session): session opened for user jason by (uid=0)
Jun 25 00:35:35 localhost pam: gdm-password[4771]: pam_unix(gdm-password:session): session closed for user jason
Jun 25 00:35:48 localhost login: pam_unix(login:session): session opened for user jason by jason(uid=0)
Jun 25 00:35:48 localhost login: Mount of private directory return code [256]
Jun 25 00:35:48 localhost login: LOGIN ON tty3 BY jason

/var/log/messages - gdm-password failed mount
Jun 25 00:41:12 localhost pam: gdm-password[7995]: Mount of private directory return code [256]


I hope I'm being more helpful than annoying...
Comment 44 Jason Elwell 2009-06-25 01:03:24 EDT
Trio of triple posts.
Ok, i finally RTFM looking at post 1.  I am good to go!  It ALL works now.  I removed the line from login and gdm-password and added to /etc/pam.d/system-auth and all works automagically!

Thanks again Michal!!
Comment 45 Jason Elwell 2009-06-25 01:13:13 EDT
I got so excited...but for naught.  It didn't survive a reboot.  The folder didn't mount automatically.  I must not have unmounted properly before, testing.  Too tired.  But this is now a different bug.
Comment 46 Michal Hlavinka 2009-06-25 02:28:21 EDT
Sachin:
(In reply to comment #41)
> I tried the new rpm from comment 40.
> 
> Following is the out come.
> 
> Private does not automount when I login from the gnome session.

So, to be clear: first, when using login automount, you've got mounted Private dir, but file names were still encrypted. Now, after login, it's not mounted at all, right?

Change broken mount (without filenames) -> not mounting would be expected due to some changes in the code.

> When I try to do the console or ssh login to my box. Everything works fine 
> Private directory is mounted, filename and contents are unencrypted.

ok, so automount is broken completely, manual mount works, right?

> /var/log/messages
> -----------------
> Jun 24 09:15:20 DL03044 mount.ecryptfs_private: It seems FNEK is supported

this means it things, it should use file name encryption

> Jun 24 09:15:20 DL03044 mount.ecryptfs_private: CHECK: FEKEK in keyring? :
> 126269642
> Jun 24 09:15:20 DL03044 mount.ecryptfs_private: CHECK: FNEK in keyring? :
> 502885670

this is check before mounting, it (non-negative value) means that key is in the keyring. 

> Jun 24 09:15:23 DL03044 umount.ecryptfs_private: It seems FNEK is supported
> Jun 24 09:15:23 DL03044 umount.ecryptfs_private: CHECK: FEKEK in keyring? :
> 126269642
> Jun 24 09:15:23 DL03044 umount.ecryptfs_private: CHECK: FNEK in keyring? :
> 502885670
> 
> /var/log/secure
> 
> Jun 24 09:15:17 DL03044 sshd[2165]: pam_sm_authenticate: Called
> Jun 24 09:15:17 DL03044 sshd[2165]: pam_sm_authenticate: username = [sachin]
> Jun 24 09:15:17 DL03044 sshd[2165]: Kernel module version : 375
> Jun 24 09:15:18 DL03044 sshd[2180]: fnek insert called
> Jun 24 09:15:19 DL03044 sshd[2180]: fekek insert called
> Jun 24 09:15:20 DL03044 sshd[2165]: Accepted password for sachin from 127.0.0.1
> port 51966 ssh2
> Jun 24 09:15:20 DL03044 sshd[2165]: pam_unix(sshd:session): session opened for
> user sachin by (uid=0)
> Jun 24 09:15:20 DL03044 sshd[2165]: Mount of private directory return code [0]
> Jun 24 09:15:23 DL03044 sshd[2165]: pam_unix(sshd:session): session closed for
> user sachin
> Jun 24 09:15:23 DL03044 sshd[2165]: Mount of private directory return code [0]
Comment 47 Michal Hlavinka 2009-06-25 02:47:02 EDT
Jason:
(In reply to comment #42)
> Thank you for your persistence, Michal!  
> Success!  I have a pretty icon that shows up in my Private folder.  When I log
> into Gnome, I only have to launch once. I put in my password (each time I log
> in) and it works the first time.

I suppose you mean the icon "Access Your Private Data", right?

> This works for my 2 machines one is 64 bit, one 32 bit.
> Could it be applicable that both were installed from live CDs?

so, do you have any other machine where this package does not work? What's it theirs log?
 
> I don't know what the expected outcome is but: 
> No auto mount neither via ssh nor gdm login.  

you need to do some (dangerous) /etc/pam.d/syste-auth modifications

> I am prompted for my password once each time I log in.

you mean after you click that "Access Your..." icon, right?

> /var/log/messages
> Jun 24 22:14:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fnek
> insert called
> Jun 24 22:14:37 localhost ecryptfs-insert-wrapped-passphrase-into-keyring:
> fekek insert called
> Jun 24 22:14:39 localhost mount.ecryptfs_private: It seems FNEK is supported
> Jun 24 22:14:39 localhost mount.ecryptfs_private: CHECK: FEKEK in keyring? :
> 683175303
> Jun 24 22:14:39 localhost mount.ecryptfs_private: CHECK: FNEK in keyring? :
> 490809149
> 
> /var/log/secure
> *nothing relevant*  

this (should) mean everything is ok, check for fnek support is successful, both keys are in the keyring

(In reply to comment #43)
> One last bit of info for tonight:
> I checked my working Ubuntu machine.  On my Fedora machines, there is no call
> to pam_ecrpytfs.so.  I added the line:
> session optional    pam_ecrpytfs.so unwrap
> to both /etc/pam.d/login and /etc/pam.d/gdm-password (i /think/ those would be
> the corresponding "right" ones)
> 
> Now...I can see the dir trying to mount on login, but failing with:


beware, don't change anything under /etc/pam.d/ if you are not sure what are you doing, result of just a typo can be a system where you can't log in. And it's not that simple just add some line, other following lines depends on all forgoing ones

system-auth modifications from Ubuntu can't be used, because (long story), there is already filled request for authconfig, which needs some changes to be able to live together with ecryptfs pam module

> I hope I'm being more helpful than annoying...  

don't worry :o)

(In reply to comment #44)
> Trio of triple posts.
> Ok, i finally RTFM looking at post 1.  I am good to go!  It ALL works now.  I
> removed the line from login and gdm-password and added to
> /etc/pam.d/system-auth and all works automagically!

well and this not working is exactly the problem why Sachin has opened this bug

(In reply to comment #45)
> I got so excited...but for naught.  It didn't survive a reboot.  The folder
> didn't mount automatically.  I must not have unmounted properly before,
> testing.  Too tired.  But this is now a different bug.  

no, this is exactly this one :o)
Comment 48 Michal Hlavinka 2009-06-25 09:21:37 EDT
Sachin:
Jason:

please try this package:
build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1435542

i586:
http://koji.fedoraproject.org/koji/getfile?taskID=1435552&name=ecryptfs-utils-75-4.fc11.0.bz495143.1.i586.rpm

x86_64:
http://koji.fedoraproject.org/koji/getfile?taskID=1435550&name=ecryptfs-utils-75-4.fc11.0.bz495143.1.x86_64.rpm

this fixes it for me, I've found that gdm uses somehow modified pam authentication process, so you alseo need to do this (as root):

cat </etc/pam.d/system-auth >/etc/pam.d/password-auth

and it should work
Comment 49 Sachin Garg 2009-06-25 14:30:16 EDT
So, to be clear: first, when using login automount, you've got mounted Private
dir, but file names were still encrypted. Now, after login, it's not mounted at
all, right?

yes

ok, so automount is broken completely, manual mount works, right?

yes
Comment 50 Jason Elwell 2009-06-26 00:29:36 EDT
To summarize for clarity...
###Before today:
I multi-posted.
My files' names are no longer encrypted as they were in the beginning.
After I re-read Sachin's post, I followed the directions found at:
http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt
(as a side note, /etc/pam.d/gnome-screensaver does call /etc/pam.d/system-auth)
I added the short function to mount my Private folder to .bash_profile.
I added pam_ecryptfs.so to /etc/pam.d/system-auth
(Last year, I screwed up pam trying to set up LDAP...Live CD saved me [why cant it be as easy as Win-dos..that
and when will a replacement for Exchange ever come out.  Rant: x8005007 is NOT a reasonable error message...at 
least M$ replaced their site-search-random-result generator with a search engine] sorry...back to the topic...)

Manual mount works perfectly, automount is broken.
When I log in, I have to launch ecryptfs-mount-private manually to decrypt my files.
Each session I must enter my password to access encrypted files.
My Private folder does not mount nor unmount /automatically/.

###Today:
I wrote everything down before I posted.
I removed the .bash_profile function.
I uninstalled the previous rpm:ecryptfs-utils-75-4.fc11.x86_64.
I rebooted.
I installed the latest rpm:ecryptfs-utils-75-4.fc11.0.bz495143.1.x86_64.
I ran: 
# cat </etc/pam.d/system-auth >/etc/pam.d/password-auth
I rebooted and logged into gdm.
Private folder did not automount.
I ran ecryptfs-mount-private from gnome-terminal
The message:"Inserted auth tok with sig [384a3b155d3fdff9] into the user session keyring" was displayed.

$ keyctl list @u
2 keys in keyring:
628024943: --alswrv   501   501 user: bb52a2629d753e92
1011060010: --alswrv   501   501 user: 384a3b155d3fdff9

$ mount
/home/test/.Private on /home/test/Private type ecryptfs (ecryptfs_sig=384a3b155d3fdff9,ecryptfs_fnek_sig=bb52a2629d753e92,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

/var/log/secure:
Jun 25 23:24:09 localhost pam: gdm-password[2760]: pam_unix(gdm-password:session): session opened for user test by (uid=0)
Jun 25 23:24:55 localhost pam: gdm-password[2760]: pam_unix(gdm-password:session): session closed for user test

/var/log/messages:
Jun 25 23:24:09 localhost pam: gdm-password[2760]: pam_sm_open_session: Called
Jun 25 23:24:09 localhost pam: gdm-password[2760]: mount_private_dir: Called
Jun 25 23:24:09 localhost pam: gdm-password[2760]: private_dir: Called
Jun 25 23:24:09 localhost pam: gdm-password[2760]: fetch_pwd: Called
Jun 25 23:24:09 localhost pam: gdm-password[2774]: private_dir: Checking keys before mount
Jun 25 23:24:09 localhost pam: gdm-password[2774]: fetch_sig(/home/test, 0): Called
Jun 25 23:24:09 localhost pam: gdm-password[2774]: failed: -1 key not in keyring :-( Required key not available
Jun 25 23:24:09 localhost pam: gdm-password[2774]: private_dir: Cant read 0. key sig
Jun 25 23:24:09 localhost pam: gdm-password[2774]: fetch_sig(/home/test, 1): Called
Jun 25 23:24:09 localhost pam: gdm-password[2774]: failed: -1 key not in keyring :-( Required key not available
Jun 25 23:24:09 localhost pam: gdm-password[2774]: private_dir: Cant read 1. key sig
Jun 25 23:24:09 localhost pam: gdm-password[2760]: Mount of private directory return code [256]
Jun 25 23:24:35 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fnek insert called
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: ecryptfs_add_auh_tok_to_keyring : 0
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: was key inserted? : 628024943
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fnek insert returned 628024943
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: fekek insert called
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: ecryptfs_add_auh_tok_to_keyring : 0
Jun 25 23:24:36 localhost ecryptfs-insert-wrapped-passphrase-into-keyring: was key inserted? : 1011060010
Jun 25 23:24:36 localhost mount.ecryptfs_private: It seems FNEK is supported
Jun 25 23:24:36 localhost mount.ecryptfs_private: CHECK: FEKEK in keyring? : 1011060010
Jun 25 23:24:36 localhost mount.ecryptfs_private: CHECK: FNEK in keyring? : 628024943
Jun 25 23:24:55 localhost pam: gdm-password[2760]: pam_sm_close_session: Called
Jun 25 23:24:55 localhost pam: gdm-password[2760]: umount_private_dir: Called
Jun 25 23:24:55 localhost pam: gdm-password[2760]: private_dir: Called
Jun 25 23:24:55 localhost pam: gdm-password[2760]: fetch_pwd: Called
Jun 25 23:24:55 localhost pam: gdm-password[2760]: Mount of private directory return code [0]
Jun 25 23:24:55 localhost umount.ecryptfs_private: It seems FNEK is supported
Jun 25 23:24:55 localhost umount.ecryptfs_private: CHECK: FEKEK in keyring? : 1011060010
Jun 25 23:24:55 localhost umount.ecryptfs_private: CHECK: FNEK in keyring? : 628024943

# cat /etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
session	    required      pam_ecryptfs.so unwrap
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
Comment 51 Michal Hlavinka 2009-06-26 04:06:08 EDT
(In reply to comment #50)
> To summarize for clarity...
> ###Before today:
> I multi-posted.
> My files' names are no longer encrypted as they were in the beginning.
> After I re-read Sachin's post, I followed the directions found at:
> http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt

Do not do this. This document is unfortunately badly outdated. There are other bugs filled against documentation, but it's not fixed, because there is actually nothing to write there. I'm trying to get this working automatically, but authconfig needs some changes first.

> ###Today:
> I wrote everything down before I posted.
> I removed the .bash_profile function.
> I uninstalled the previous rpm:ecryptfs-utils-75-4.fc11.x86_64.
> I rebooted.
> I installed the latest rpm:ecryptfs-utils-75-4.fc11.0.bz495143.1.x86_64.
> I ran: 
> # cat </etc/pam.d/system-auth >/etc/pam.d/password-auth

well, this was not replacement, but addition, you need system-auth from this bz first. Just both files should contain the same content.

What is required to get this working (how I test this):
1) add new user (or use your current user)

2) add user to ecryptfs group (usermod -G ecryptfs <username>) or make sure user is member of ecryptfs group (id <username>)

3) log in as that user and run ecryptfs-setup-private (you don't need to do this if you are using your current user name and ecryptfs-mount-private works for you, also don't do this for you current user name if you have any data in Private)

4) use /etc/pam.d/system-auth from this bug

(now it should work for console and ssh login)

5) copy /etc/pam.d/system-auth over /etc/pam.d/password-auth 

and it should work even for gdm login

note: If you are using selinux do

restorecon -R /etc/pam.d/

to be sure files have correct context or you won't be able to log in

> I rebooted and logged into gdm.
> ...
> /var/log/messages:
> Jun 25 23:24:09 localhost pam: gdm-password[2760]: pam_sm_open_session: Called
> Jun 25 23:24:09 localhost pam: gdm-password[2760]: mount_private_dir: Called
> Jun 25 23:24:09 localhost pam: gdm-password[2760]: private_dir: Called
> Jun 25 23:24:09 localhost pam: gdm-password[2760]: fetch_pwd: Called
> Jun 25 23:24:09 localhost pam: gdm-password[2774]: private_dir: Checking keys
> ....

> # cat /etc/pam.d/password-auth
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        required      pam_deny.so
> 
>....
> 
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet
> use_uid
> session     required      pam_unix.so  

there is something wrong here... your password-auth does not contain pam_ecryptfs module, if you have ran # cat </etc/pam.d/system-auth >/etc/pam.d/password-auth, then even system-auth doesn't contain pam_ecryptfs module. This means pam_ecryptfs module is not called and you can't get the messages you have in /var/log/messages, you've probably forgot pam_ecryptfs in some /etc/pam.d/... file.

this should tell you where:
grep -r pam_ecryptfs /etc/pam.d
Comment 52 Jason Elwell 2009-06-27 16:50:03 EDT
Sorry I messed that up.  That's how i roll :o)

### Pasted system-auth from https://bugzilla.redhat.com/attachment.cgi?id=339007
# cat </etc/pam.d/system-auth >/etc/pam.d/password-auth

$ grep ecrypt /etc/pam.d/*
/etc/pam.d/password-auth:auth        optional      pam_ecryptfs.so unwrap
/etc/pam.d/password-auth:password    optional      pam_ecryptfs.so unwrap
/etc/pam.d/password-auth:session     optional      pam_ecryptfs.so unwrap
/etc/pam.d/password-auth-ac:auth        optional      pam_ecryptfs.so unwrap
/etc/pam.d/password-auth-ac:password    optional      pam_ecryptfs.so unwrap
/etc/pam.d/password-auth-ac:session     optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth:auth        optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth:password    optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth:session     optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth-ac:auth        optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth-ac:password    optional      pam_ecryptfs.so unwrap
/etc/pam.d/system-auth-ac:session     optional      pam_ecryptfs.so unwrap
$ cat /etc/selinux/config 
...
SELINUX=disabled
...
$ sudo reboot
!!!
@@@ My user account now automounts on login via gdm and tty!! @@@
!!!
# useradd -G ecryptfs test
# passwd test
Changing password for user test.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

[test@localhost ~]$ ecryptfs-setup-private
Enter your login passphrase: 
Enter your mount passphrase [leave blank to generate one]: 

************************************************************************
YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
eb87ca41728d654c67f30ed91f4eb503
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************



Error: Inserting key into the user session keyring failed [946979803]
Info: Check the system log for more information from libecryptfs
ERROR: Could not add passphrase to the current keyring
$ keyctl list @u
1 key in keyring:
946979803: --alswrv   501   501 user: 4adea5ca63912b09

# tail /var/log/messages
Jun 27 15:43:27 localhost ecryptfs-add-passphrase: ecryptfs_add_auh_tok_to_keyring : 0
Jun 27 15:43:27 localhost ecryptfs-add-passphrase: was key inserted? : 946979803


# less /var/log/secure
Jun 27 15:43:03 localhost login: pam_sm_authenticate: Called
Jun 27 15:43:03 localhost login: pam_sm_authenticate: username = [test]
Jun 27 15:43:03 localhost login: ecryptfs_pam_automount_set: Called
Jun 27 15:43:03 localhost login: Pam automount not set
Jun 27 15:43:03 localhost login: pam_unix(login:session): session opened for user test by LOGIN(uid=0)
Jun 27 15:43:03 localhost login: pam_sm_open_session: Called
Jun 27 15:43:03 localhost login: mount_private_dir: Called
Jun 27 15:43:03 localhost login: private_dir: Called
Jun 27 15:43:03 localhost login: fetch_pwd: Called
Jun 27 15:43:03 localhost login: pam_sm_setcred: Called
Jun 27 15:43:03 localhost login: LOGIN ON tty2 BY test
...
###later changing password for test:
Jun 27 16:46:51 localhost passwd: eCryptfs PAM passphrase change module retrieved a NULL passphrase; nothing to do
Jun 27 16:47:02 localhost passwd: pam_sm_chauthtok: Called
Comment 53 Michal Hlavinka 2009-07-16 09:55:57 EDT
sorry for slow response, I'm still quite overloaded... :-(

do I understand your last comment correctly? your current user account now works, but new account produces error messages and does not work at all?

when you setup new account, it failed just when doing ecryptfs-setup-private

when logged out and logged in, it was not working

also changing user password (which way, via passwd?) it was not working


right?


sachin:

did #cat </etc/pam.d/system-auth >/etc/pam.d/password-auth worked for you or not?
Comment 54 Jason Elwell 2009-07-16 23:40:55 EDT
Michal,
     No worries, I know what it is to be overloaded!  Your summary is correct.  Pre-existing users work flawlessly.  New users cannot be setup to use ecryptfs (ecryptfs-setup-private) at all.  
     What I had done was setup a user and it's password as root.  I then logged in as that new user.  As that user, I ran ecryptfs-setup-private which errored out.  I then ran passwd as the user to see if that would make any difference.  The new user seems to only have one key in it's keyring.  My working user has 2 keys in it's keyring.
      When I login as the new user, the same messages appear in /var/log/secure as I listed in Comment #52.  When I run ecryptfs-setup-private as the user, the same messages (except for keys) appear in /var/log/messages as listed in Comment #52.
      It seems that for new users running ecryptfs-setup-private, ecryptfs-add-passphrase fails on line 396.  I tried running "ecryptfs-add-passphrase --fnek" manually to test, which doesn't appear to work either.  Which I googled and read Bug 500810.  Which you are already working on :)  Let me know how I can help!
Comment 55 Michal Hlavinka 2009-07-21 04:16:16 EDT
ok, next round :o)

I've updated ecryptfs-utils, it now contains over 20 bug fixes (including #500810) I've sent upstream, so lets give it a try. Packages with additional debug output are here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1489053

selinux is in permissive mode

1st console:
su -
curl https://bugzilla.redhat.com/attachment.cgi?id=339007 >/etc/pam.d/system-auth
cat </etc/pam.d/system-auth >/etc/pam.d/password-auth
useradd -G ecryptfs testuser2
passwd testuser2

2nd console:
su - testuser2
ecryptfs-setup-private
-> no error, Private is not mounted, keyring is empty

ecryptfs-mount-private
-> mounted, file name encryption is working

echo "hello world" >Private/hello.txt
ll Private
-> -rw-rw-r--. 1 testuser2 testuser2 12 2009-07-21 10:01 hello.txt

ecryptfs-umount-private
ll Private
-> umounted info, keyring empty

logout
-> keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
(this is cosmetic harmless bug)

su - testuser2
cat Private/hello.txt
-> hello world, so it works

logout
-> umounted

1st console(root):
su - testuser2
-> su: cannot set groups: Operation not permitted -- wtf? this is a bug, but still harmless, Private is not mounted (as expected), 

ls .Private/
-> ECRYPTFS_FNEK_ENCRYPTED.FWbaTOUBV18HOUSkX0nhz6yOyshfgoLrQa51YGDbTa8a5v4yCAiQJ0N7r---

logout
-----------------

after logging in gnome it still works


so please test new package if it works for you
Comment 56 Sachin Garg 2009-07-21 17:06:16 EDT
Thanks Michael.. For the hard work. I tried the new package ..

After doing this cat </etc/pam.d/system-auth >/etc/pam.d/password-auth Private does mount after login.

I followed the steps given in the comment 55. Everything works. 
But after reboot at the first login the filename are still encrypted. But when I login as the different user who also have private directory configured filenames are not encrypted in Private directory.
Comment 57 Jason Elwell 2009-07-22 01:59:04 EDT
Indeed, thank you!  I'm sad to report that I believe I am getting the same results as Sachin.  I followed the instructions in Comment #55.  All went exactly as stated.  

I rebooted, and logged into gdm as testuser2 and the file name were still encrypted (clear data).  I logged out and back in again and the file names were unencrypted.  I rebooted a second time and got the same results.  After the third reboot, I logged in as testuser2 but into tty2.  The error "keyctl_search: Required key not available" was displayed.  I logged out and back in again and all worked as expected.  My existing user does the same thing.  

It appears that the very first user to log in has encrypted file names.  All subsequent logins work as expected, regardless of having logged in once before.  There is nothing in /var/log/{messages,secure} indicating an error.

For that first login, running: 
$ ecryptfs-umount-private && ecryptfs-mount-private 
seems to fix the issue as well.  Looking at the output of the mount command for the encrypted file name session, ecryptfs_fnek_sig seems to be missing compared to the output of the clear-filename mount output.  I wish I had more info for you but there isn't much to give :(
Comment 58 Michal Hlavinka 2009-07-28 15:23:12 EDT
Well... I was able to reproduce this first mount problem, but I've prepared new version (again), where this should be fixed. Now, I can redo everything from comment #55 (that two small bugs are still there) and it mounts fine even first time after reboot :o)

I *hope* this is going to be the final fix...

packages are here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=122815
Comment 59 Sachin Garg 2009-07-28 16:34:37 EDT
Thanks works for me .. I really appreciate the hard work..

Also on sidenote when can we expect the out of the box experience for Private directory (ie no pam.d changes)
Comment 60 Michal Hlavinka 2009-07-29 02:49:04 EDT
(In reply to comment #59)
> Thanks works for me .. I really appreciate the hard work..
> 
> Also on sidenote when can we expect the out of the box experience for Private
> directory (ie no pam.d changes)

Fedora uses/can use a lots of weirdo auth methods, so pam modifications are little bit more difficult than usual. But thanks this bug and your patience we know more about changes required, so we are a few steps closer. We still need to do some modifications to pam config tools, because of the config auto-generation (# This file is auto-generated. # User changes will be destroyed the next time authconfig is run.) and that tools does not know about ecryptfs (yet).

I'll start working on it now
Comment 61 Michal Hlavinka 2009-07-29 02:55:35 EDT
Fixed in ecryptfs-utils-78-1.fc11

I'm going to push it to updates-testing for two weeks (or +3 karma) and then to updates.

I'm not linking this bug to bodhi updates, because I don't want this get too much attention. Manual modifications to pam config files are required and it can break your system if you don't know what are you doing for example if you use different auth method (ldap,...).

If you find another issue (different than %subj or pam-automount) open new bug.
Comment 62 Sachin Garg 2009-07-29 10:40:02 EDT
Once again a big thanks ..
Comment 63 Jason Elwell 2009-07-29 20:03:24 EDT
Sorry for being late.  I just wanted to confirm that everything works perfectly.  Thanks again for working on this.

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