Some update.
Since I changed the /etc/pam.d/system-auth file I got the log (reported by logwatch) full of lines like:

...
 Jan 31 00:01:01 lazy crond[25596]: Sigfile not found
...

Once the "pam_ecryptfs.so" module were removed (commented) the error was not reported anymore.

Interesting thing is that "Sigfile not found" error is reported by "crond" and it relates to different jobs, like "sysstat".

It is unclear to me what is the relationship between pam, ecryptfs and cron, but something seems to be fishy, here.

Any ideas?

pg

(In reply to comment #1)
> Some update.
> Since I changed the /etc/pam.d/system-auth file I got the log (reported by
> logwatch) full of lines like:
> 
> ...
> 
> Any ideas?
> 

unfortunately, I can't make this working (for now). I'm still trying and I'll let you know when I get the answer.

I've made previous comment private, because it contained wrong pam configuration


I've find it out... 

before it'll be fixed, here is available workaround:

look at
http://bazaar.launchpad.net/~kirkland/ecryptfs/ecryptfs-utils/annotate/head%3A/doc/ecryptfs-pam-doc.txt

1) use ecryptfs-setup-private

2) put correct line in /etc/fstab (in the doc. line 78)

3) put correct lines in ~/.bash_profile (line 87+)

4) change /etc/pam.d/system-auth to this ( *ONLY* if you don't use any other
modification to this file and only if you are not using ldap/kerb5/other
non-default authentication system)

#%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        [success=2 default=ignore]  pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
auth        required      pam_permit.so
auth        optional      pam_ecryptfs.so unwrap

account     required      pam_unix.so
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    optional      pam_ecryptfs.so unwrap
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
session     optional      pam_ecryptfs.so unwrap

btw, it's possible ecryptfs-setup-private doesn't work, tell me if you find any
problem

Thanks for the hint, I'll try to fix the /etc/pam.d/system-auth as suggested.

Unfortunately, point 2) is not really feasible, since I cannot have an entry in /etc/fstab for each user. Point 3) is somehow possible, but not really wanted.
I can anyway try this approach with my test user, just to confirm it.

In any case, as mentioned in comment #1, when it was working, i.e. unwrapping manually the key, the login/out process was mounting/umounting ~/Private without the need of changes in /etc/fstab and/or ~/.bash_profile, so it seems to me that the pam thing was faulty.

About "ecryptfs-setup-private", to me it was working fine, I cannot recall any problem. Actually, it was really working well!

Thanks again!

pg

OK, I tried the /etc/fstab variant, but it did not work.

Typing "mount -i $HOME/Private" returns:

mount: No such file or directory

The directory $HOME/Private and $HOME/.Private are, of course, there and /etc/fstab has a proper entry as per link (even if there is a mixup between ~/.Private and ~/Private in the explanation). 
Is it not clear to me which file or directory is supposed to be missing.

Typing "mount $HOME/Private" leads to the request of key type and similar.

As a side note, re-adding the "pam_ecryptfs.so" entries to /etc/pam.d/system-auth was causing again the flooding in /var/log/cron  of:

...
 Feb 12 23:20:01 lazy crond[10650]: Sigfile not found
 Feb 12 23:20:01 lazy CROND[10650]: Sigfile not found
 Feb 12 23:30:01 lazy crond[11845]: Sigfile not found
 Feb 12 23:30:01 lazy CROND[11845]: Sigfile not found
...

As a final note.

Using "ecryptfs-insert-wrapped-passphrase-into-keyring" manually, from the test user, allowed to mount the "Private" directory later with the normal "mount.ecryptfs_private" command.

Hope this helps,

pg

Checking the logs I found, among all, the following:

...
Could not find key with description: [26e3bde55ca4d62b]
process_request_key_err: No key
Could not find valid key in user session keyring for sig specified in mount option: [26e3bde55ca4d62b]
...

So, either the key in the keyring has different sig (different key) or there is no key in the keyring.
Which tools could be used to check the keyring?

Thanks,

pg

could you test if this works with new ecryptfs-utils?

http://koji.fedoraproject.org/koji/buildinfo?buildID=82856

it's now pending to updates-testing, I don't know how long does it take.

if new ecryptfs-utils doesn't work
0) check if ecryptfs module is loaded
# lsmod | grep ecryptfs
if it's not loaded, try next steps, if it fails, try to load module
# modprobe ecryptfs
and repeat this steps

1) attach ecryptfs lines from /etc/fstab, /var/log/messages and matching pam lines from /var/log/secure (after login) - pam module should take passphrase, unwrap your mount passphrase and put it in keyring

2)setup ecryptfs + pam setup and attach output of 
# keyctl list @u
after login

3) does ecryptfs-mount-private work?

4) if not, use
# ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
to obtain your mount passphrase and try to mount it with this passphrase
#mount -t ecryptfs $HOME/.Private $HOME/Private


5) after mount (by hand or by ecryptfs-mount-private) check output of
# mount | grep ecryptfs_sig
if it contains the key sig it can't find during login

(In reply to comment #7)
> Which tools could be used to check the keyring?

keyctl list @u

(In reply to comment #6)
> The directory $HOME/Private and $HOME/.Private are, of course, there and
> /etc/fstab has a proper entry as per link (even if there is a mixup between
> ~/.Private and ~/Private in the explanation). 
> Is it not clear to me which file or directory is supposed to be missing.

both directories should be there... ecryptfs-setup-private creates them

ecryptfs can mount (decrypt) files over the source directory

mount -t ecryptfs /encrypted /encrypted # when not mounted, this contains encrypted files you can send via email or backup, when mounted, this contains decrypted files you can read and write to


mount -t ecryptfs ~/.Private ~/Private 
is something like mount --bind, but in ~/.Private directory are encrypted files (all the time whenever mounted or not) and in ~/Private are decrypted files available to read and write if mounted, this directory is empty otherwise. This second approach is because backups / autobackups (don't backup decrypted files accidentally) and you can copy/send encrypted files wherever you want.

Some partial update.

(In reply to comment #8)
> could you test if this works with new ecryptfs-utils?
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=82856
> 
> it's now pending to updates-testing, I don't know how long does it take.

Done.

> if new ecryptfs-utils doesn't work
> 0) check if ecryptfs module is loaded
> # lsmod | grep ecryptfs
> if it's not loaded, try next steps, if it fails, try to load module
> # modprobe ecryptfs
> and repeat this steps

Well, I understand the concern :-), but of course the module is there (checked).

> 1) attach ecryptfs lines from /etc/fstab, /var/log/messages and matching pam
> lines from /var/log/secure (after login) - pam module should take passphrase,
> unwrap your mount passphrase and put it in keyring

This comes later. I tried without entry in /etc/fstab.

> 2)setup ecryptfs + pam setup and attach output of 
> # keyctl list @u
> after login

This says:

keyring is empty

> 3) does ecryptfs-mount-private work?

This works fine. It asks for the login password and then the ~/Private is mounted. After that, "keyctl list @u" returns:

1 key in keyring:
452293390: --alswrv   502   502 user: 26e3bde55ca4d62b

> 5) after mount (by hand or by ecryptfs-mount-private) check output of
> # mount | grep ecryptfs_sig
> if it contains the key sig it can't find during login

That is:

/home/atest/.Private on /home/atest/Private type ecryptfs (ecryptfs_sig=26e3bde55ca4d62b,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

One further comment. To switch to the "atest" user, I used two methods. One is the simple "su - atest" from terminal, the other is the "fast-user-switch" thing.
Both seem to lead to the same result, i.e. the key is not inserted in the keyring.

Breakthrough!
While writing (I'll not delete the previous text anyway, maybe it is still useful) I just noticed a small difference in the /etc/pam.d/system-auth file.
Mine has the following:

...
auth        sufficient    pam_unix.so nullok try_first_pass
...

While you suggested:

...
auth        [success=2 default=ignore]  pam_unix.so nullok try_first_pass
...

Changing correctly to this second one, seem to have fixed the issue (with the new ecryptfs-utils).

I'll keeping running like this, if everything will work without issues in the next few days I'll close this bug.
Of course, I'm curious to know what's the difference between the two setups.

I'll anyway leave #479319 open since the solution should be somehow documented.

Thanks again for your support!

pg

Another update.

Now it seems to work even too well...

If, as "root", I type "su - atest", not only (as expected) I can become "atest", but /home/atest/Private results mounted, i.e. the files are readable.

Is this expected?
Is there anything could be done to avoid it?

Thanks!

pg

(In reply to comment #10)
> While writing (I'll not delete the previous text anyway, maybe it is still
> useful) I just noticed a small difference in the /etc/pam.d/system-auth file.
> Mine has the following:
> 
> ...
> auth        sufficient    pam_unix.so nullok try_first_pass
> ...
> 
> While you suggested:
> 
> ...
> auth        [success=2 default=ignore]  pam_unix.so nullok try_first_pass
> ...
> 

yes, it wasn't an example for inspiration, it was complete replacement for system-auth :)

> keyring is empty

this means pam_ecryptfs wasn't called - no key was inserted into the keyring

> auth        sufficient    pam_unix.so nullok try_first_pass

and this proves it - sufficient means if this module returns "OK", don't call following modules

> Now it seems to work even too well..

I'll check it out, but it seems to be related to #480547, try to add ecryptfs_unlink_sigs to mount options

(In reply to comment #11)
> Another update.
> 
> Now it seems to work even too well...
> 
> If, as "root", I type "su - atest", not only (as expected) I can become
> "atest", but /home/atest/Private results mounted, i.e. the files are readable.
> 
> Is this expected?
> Is there anything could be done to avoid it?

if you login as user1 and do
# su - --login user2
you should get ~/Private mounted - you are user2 now and you've entered the password

when you are root and do
# su - --login user2
you should *not* get ~/Private mounted only because you are not asked for password (the same thing if you use autologin to KDE/Gnome - you are not entering password so ~/Private won't be mounted)

what happens:
when you login, pam is used to authenticate you - pam_unix reads password and verifies it, then pam_ecryptfs gets the password and unwraps your mount passphrase (mount passphrase is stored encrypted by your login password) and puts the mount passphrase into the keyring (keyctl list @u will show a list with that passphrase). After login  ~/.bash_profile is executed and it mounts your ~/Private directory using passphrase from the keyring.

so if you don't enter passpword pam_ecryptfs has no password to decrypt mount passphrase

so if you have data accessible one of the things happend:
1) ~/Private was not umounted
2) ~/Private was umounted but keyring wasn't cleared (works only since e-u v. 70)

note: when you have ~/Private mounted for user2 it's mounted for everyone - everyone who can read files from that directory is also able to read decrypted files (when mounted)

you can check this: if you do

# su - --login user2 

after reboot and before user2 has logged in, you definitely should not get mounted ~/Private

so when you have this problem:
1) is user atest logged in?
2) is /home/atest/Private mounted before you try su ?
3) when you umount ~/Private directory (still logged as atest) check if key was removed from keyring : keyctl list @u

small change...

after ecryptfs-setup-private and system-auth modifications, there should be no modifications to /etc/fstab nor ~/.bash_profile -- that how-to document is outdated

the 'su' problem is verified and will be fixed in ecryptfs-utils v. 71 (not yet released)

thanks for testing

(In reply to comment #14)
> small change...
> 
> after ecryptfs-setup-private and system-auth modifications, there should be no
> modifications to /etc/fstab nor ~/.bash_profile -- that how-to document is
> outdated

Well, this was how I tested all the time :-), since, as mentioned, the /etc/fstab is not an option for me.

> the 'su' problem is verified and will be fixed in ecryptfs-utils v. 71 (not yet
> released)

OK, that's good to read.
Does this mean there is no need of further investigation from my side on this item?

> thanks for testing

Thank you for your support.
I hope this will lead to a better software.

There are still some issues I can see.
I mention them here, eventually I can open another bug or two.
Let me know.

First of all, the new ecryptfs-utils, when the "ecryptfs-setup-private" is invoked, tries to link a couple of files in the ~/Private directory.
These are visible when there is no mount (on ~/Private of course).
In the new (70) release the links are broken, i.e. the source files do not exist.
They are:

Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

It seems to me they're just missing in the rpm, maybe.

Second, the default mode for Private, when unmounted, is 500 or r-x------ and, maybe for this reason, the above links cannot be always be created.
Actually, sometimes they were, but lately, after "ecryptfs-setup-private", I got the error "Permission denied".

The old "ecryptfs-utils" package was creating a different link:

THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again -> /sbin/mount.ecryptfs_private

Which was OK.
So, there are two problems here, one is the missing files, the other is the, inexplicable "Permission denied".

Last, if I shut down (from menu->shutdown) the PC, without logout, during shutdown it keeps shouting about the fact that it cannot umount /home (it is a separate LVM volume) because libecryptfs has open files on it.

Should I open separate bugs or can we handle everything here?

Thanks again.

pg

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

(In reply to comment #15)

> Last, if I shut down (from menu->shutdown) the PC, without logout, during
> shutdown it keeps shouting about the fact that it cannot umount /home (it is a
> separate LVM volume) because libecryptfs has open files on it.

I had a more careful look at the issue and the reported message.
The error is about mount.ecryptfs not being able to open shared object libecryptfs.so.0 during filesystem unmount in the last part of shutdown.

The reason *could* be that /usr is unmounted before /home (they're on different LVM volumes) and, consequently, mount.ecryptfs cannot run properly anymore.

If this is the case, I see the following possibilities:

1) mount.ecryptfs is linked statically
2) libecryptfs.so is moved to /lib (what about x86_64?)

Hope this helps, thanks again.

pg

> Does this mean there is no need of further investigation from my side 
> on this item?

no, not for now

> I mention them here, eventually I can open another bug or two.

Please open new bugs.

> Actually, sometimes they were, but lately, after "ecryptfs-setup-private",
> I got the error "Permission denied".

you mean the links are there after umount only sometimes? or when exactly you get the "Permission denied" error?

> shutdown it keeps shouting about the fact that it cannot umount /home 

yes, I have the same problem (not with ecryptfs), umount on shutdown isn't too smart. Open bug for this too, maybe I'll change component of that bug after some investigations.

> The reason *could* be that /usr is unmounted before /home

I think that's the point... 

Still, open new bugs for all problems you find, thanks.

Since the auto mount now works (for me) and the other issues have their own reports, I close this one.
Of course, feel free to re-open if you think it is necessary.

Thanks again for the support.

pg

> and the other issues have their own reports

Thanks for reporting them.

> , I close this one.

Please, do not change status of bugs next time, this is what assignee of the bug should decide. Just leave a comment.

> the 'su' problem is verified and will be fixed in ecryptfs-utils v. 71 (not yet
> released)

problem is little more complicated, v. 71 doesn't have the fix yet, we are still working on it.

Thanks,
Michal

(In reply to comment #20)

> Please, do not change status of bugs next time, this is what assignee of the
> bug should decide. Just leave a comment.

Oh! Sorry for that, other times I was told I could close the issue.
Nevermind, I'll try to refrain... :-)

[su]
> problem is little more complicated, v. 71 doesn't have the fix yet, we are
> still working on it.

Thanks, good to know it is addressed and someone is working on it.

BTW, it seems to me there is no bug open for the "su" problem, at least I did not find one.
I do not crave it, but if it is necessary I could do.

pg

'su' problem is related to 480547

there are two mount helpers: mount.ecryptfs and mount.ecryptfs_private

mount.ecryptfs is fixed, but the fix mount.ecryptfs_private is much more difficult

I'll fix bug #486139 and bug #486146, when packaging new version.

bug #479319 depends on authconfig (pam.d/system-auth, we didn't decide how are we going to handle it)

Michal

(In reply to comment #22)
[...]
> I'll fix bug #486139 and bug #486146, when packaging new version.

Good!
Thanks a lot!

> bug #479319 depends on authconfig (pam.d/system-auth, we didn't decide how are
> we going to handle it)

For your information (maybe you want to be CC, I was unsure on that), I opened #486152 against "authconfig" about the /etc/pam.d/system-auth story.

pg