ecryptfs fails to mount (Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING)

[Eugene San]

This is a reincarnation of Bug #1234412.

Looks like issue is not related to specific kernel versions.

Currently I am observing two Trusty (14.04) machines, with very close configuration, running same kernel:
3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64.

One is able to mount without the problem but the other is refusing:
$ mount -t ecryptfs sec sec
Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING; there is something wrong with your kernel keyring. Did you build key retention support into your kernel?

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1377924

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

Does this issue go away if you boot an earlier kernel version?

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.17 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.17-utopic/

[Eugene San (eugenesan)]

I've learned that the issue is not related to kernel version but caused by environment under which mount is executed.

On my systems (14.04), it fails when executed inside x2go session but manages to operate when connected via physical VT or SSH.

May be it's related to apparmor, but how x2go and ssh are different in that perspective? They both spawned as by sshd.
Also additional environments like vnc and rdp might be affected.

Below is strace of failing attempt.

===
"ecryptfs-add-passphrase --fnek" works but mount fails:
===
sudo strace mount -o no_sig_cache,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,passwd=dummy,ecryptfs_sig=xxxxxxxxxxxxxxxx,ecryptfs_fnek_sig=yyyyyyyyyyyyyyy -t ecryptfs /media/storage/backup/home/.ecryptfs/user/.Private /media/storage/backup/home/user
...
stat("/sbin/mount.ecryptfs", {st_mode=S_IFREG|0755, st_size=25880, ...}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb366a0bb50) = 11423
wait4(-1, Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING; there is something wrong with your kernel keyring. Did you build key retention support into your kernel?
[{WIFEXITED(s) && WEXITSTATUS(s) == 251}], 0, NULL) = 11423
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=11423, si_status=251, si_utime=0, si_stime=1} ---
exit_group(251) = ?
+++ exited with 251 +++
===

[joseph spitz (josephgrey)]

I am also getting this error, and like Eugene says, it seems to be dependent on the environment in which the mount command is executed.

I attempted to mount from inside a tmux session, and the mount failed. I detached from the tmux session, issued the very same mount command in a plain ssh terminal, and the mount succeeded.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Eugene San (eugenesan)]

The reason for the failure seems to be in default configuration of PAM for SSH.

If I understand correctly, PAM is configured to enforce session keys revocation upon termination of parent SSHD process:
--- /etc/pam.d/sshd ---
...
# Create a new session keyring.
session optional pam_keyinit.so force revoke
...
---

Some environments connect using ssh and then "detach" from it, which probably causes session key termination.

As a workaround I propose commenting out "force revoke" in /etc/pam.d/sshd.

Note: There might be security related repercussions!

[Steve Langasek (vorlon)]

This config file belongs to ssh, not to pam.

[weakish (weakish)]

@josephgrey I encountered the same situation, not working inside tmux.

[Marco Aicardi (launchpad-net-aicardi)]

@joseph spitz (josephgrey)

The same happens to me inside Byobu (tmux), with Ubuntu 14.10, Kernel 3.6.0-34

[Pieter (diepes)]

Just hit it with mosh session.

"Unable to link the KEY_SPEC_USER_KEYRING into the KEY_SPEC_SESSION_KEYRING; there is something wrong with your kernel keyring. Did you build key retention support into your kernel?"

[Pieter (diepes)]

Just using ssh and all the ecryptfs problems are gone.

I think ecrypfts should provide a better explanation, when it cant access the keyring.

Kernel:
 4.4.1-040401-generic #201601311534 SMP Sun Jan 31 20:36:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[ET (e-timotei)]

Just using ssh is not a solution.
I have long running commands (sessions) that need to run in "screen" (tmux) and also need access to files from Private.
After the ssh connection closes the Private will unmount.

[ET (e-timotei)]

I have fixed my problem with screen + private by reading this question.

http://askubuntu.com/questions/240555/how-to-prevent-ecryptfs-from-umounting-home-if-tmux-is-still-running

[naisanza (naisanza)]

Issue happens if running in tmux.