[Bug 1045886] New: ecryptfs problems with recent Tumbleweed
http://bugzilla.suse.com/show_bug.cgi?id=1045886 Bug ID: 1045886 Summary: ecryptfs problems with recent Tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening@forge.provo.novell.com Reporter: roger.whittaker@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- ecryptfs and the ecryptfs tools have stopped working correctly on recent versions of Tumbleweed. I noticed this because an existing ecryptfs Private directory could only be seen after a local login. ecryptfs-mount-private over ssh stopped working. On investigation, it is no longer possible to do ecryptfs-setup-private for a new user. $ ecryptfs-setup-private Enter your login passphrase [roger]: Enter your mount passphrase [leave blank to generate one]: ************************************************************************ YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION. ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME. ************************************************************************ Done configuring. Testing mount/write/umount/read... Inserted auth tok with sig [83ecc1d632221288] into the user session keyring Inserted auth tok with sig [90e42628446d371b] into the user session keyring mount: No such file or directory ERROR: Could not mount private ecryptfs directory In the system logs we see: 2017-06-25T07:04:39.396038+01:00 [localhost] kernel: [140502.266628] Could not find key with description: [90e42628446d371b] 2017-06-25T07:04:39.396052+01:00 [localhost] kernel: [140502.266630] process_request_key_err: No key 2017-06-25T07:04:39.396054+01:00 [localhost] kernel: [140502.266631] Could not find valid key in user session keyring for sig specified in mount option: [90e42628446d371b] 2017-06-25T07:04:39.396056+01:00 [localhost] kernel: [140502.266631] One or more global auth toks could not properly register; rc = [-2] 2017-06-25T07:04:39.396072+01:00 [localhost] kernel: [140502.266632] Error parsing options; rc = [-2] $ uname -r 4.11.6-1-default $ grep VERSION_ID /etc/os-release VERSION_ID="20170620" -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c1 --- Comment #1 from Roger Whittaker <roger.whittaker@suse.com> --- I believe the problem here is related to systemd. Previously I found that simply downgrading the kernel had no effect on this problem. And there had been no change in the version of ecryptfs-utils. But after forcing a downgrade to systemd-232-10.2, now I see success: $ ecryptfs-setup-private Enter your login passphrase [roger]: Enter your mount passphrase [leave blank to generate one]: ************************************************************************ YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION. ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME. ************************************************************************ Done configuring. Testing mount/write/umount/read... Inserted auth tok with sig [38016f72d097f6f6] into the user session keyring Inserted auth tok with sig [a6db1a352f8f2d14] into the user session keyring Inserted auth tok with sig [38016f72d097f6f6] into the user session keyring Inserted auth tok with sig [a6db1a352f8f2d14] into the user session keyring Testing succeeded. Logout, and log back in to begin using your encrypted directory. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c2 Andrei Borzenkov <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com --- Comment #2 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Roger Whittaker from comment #1)
But after forcing a downgrade to systemd-232-10.2
You forgot to say what version of systemd has problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c3 --- Comment #3 from Roger Whittaker <roger.whittaker@suse.com> --- I think the problem was introduced with Tumbleweed snapshot 20170620, which has systemd version 233 for the first time. https://lists.opensuse.org/opensuse-factory/2017-06/msg00620.html When I forced the systemd packages down to systemd-232-10.2 (on Tumbleweed 20170622), I saw the problem go away as noted in comment#1. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 Chenzi Cao <chcao@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c4 --- Comment #4 from Roger Whittaker <roger.whittaker@suse.com> --- Failing system has systemd-233-1.1.x86_64, ecryptfs-utils-108-3.2.x86_64. Now upgraded to 20170622 - problem persists. But goes away if systemd is forced down to a 232 version. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c6 --- Comment #6 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Roger Whittaker from comment #4)
Failing system has systemd-233-1.1.x86_64
The obvious difference is that with 232 no kernel keyrings were setup by default at all (we do not have pam_keyinit on TW in default configuration), while with 233 each session sets up its own keyring. Unfortunately, these keyrings seem to propagate to user sessions, messing up keys lookup. More details 1. systemd commit: commit 74dd6b515fa968c5710b396a7664cac335e25ca8 Author: Lennart Poettering <lennart@poettering.net> Date: Fri Dec 2 01:54:41 2016 +0100 core: run each system service with a fresh session keyring so far, so good. 2. Now lets look at keyrings immediately after logon bor@10:~> : Before ecryptfs-setup bor@10:~> cat /proc/keys 023c3b10 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 05088f05 I--Q--- 88 perm 3f030000 0 0 keyring _ses: 1 2344184f I--Q--- 41 perm 3f030000 1000 100 keyring _ses: 1 bor@10:~> keyctl show -x @s Keyring 0x05088f05 --alswrv 0 0 keyring: _ses 0x023c3b10 ----s-rv 0 0 \_ user: invocation_id Note - our session keyring is owned by user 0!!! So it is the one inherited from systemd service. (Heck, is there any way to list session keyrings for each process?) 3. Now let's see what happens after ecryptfs-setup runs bor@10:~> : After ecryptfs-setup bor@10:~> cat /proc/keys 023c3b10 I--Q--- 1 perm 0b0b0000 0 0 user invocation_id: 16 041560fc I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1 05088f05 I--Q--- 90 perm 3f030000 0 0 keyring _ses: 1 2344184f I--Q--- 39 perm 3f030000 1000 100 keyring _ses: 1 2540e350 I--Q--- 2 perm 1f3f0000 1000 65534 keyring _uid.1000: 2 28543b18 I--Q--- 1 perm 3f010000 1000 100 user ae0285ccbff6e3cb: 740 2dec2d68 I--Q--- 1 perm 3f010000 1000 100 user be1ad3e0687105d5: 740 bor@10:~> keyctl show -x @s Keyring 0x05088f05 --alswrv 0 0 keyring: _ses 0x023c3b10 ----s-rv 0 0 \_ user: invocation_id bor@10:~> keyctl show -x @us Keyring 0x041560fc --alswrv 1000 65534 keyring: _uid_ses.1000 0x2540e350 --alswrv 1000 65534 \_ keyring: _uid.1000 0x2dec2d68 --alswrv 1000 100 \_ user: be1ad3e0687105d5 0x28543b18 --alswrv 1000 100 \_ user: ae0285ccbff6e3cb Oops. ecryptfs adds keys to *user* keyring. This keyring is not used during default key lookup directly - only if it is linked from session (or in general other default search path) keyring. But we already have "wrong" session keyring which does *NOT* link to our user keyring. So default user session is not used and key is not found. Adding pam_keyinit.so to default session PAM service fixes it (disclaimer - I do not know whether it may have some other side effects). Note that systemd 233 actually includes it in recommended PAM configuration shipped with it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c7 --- Comment #7 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Andrei Borzenkov from comment #6)
while with 233 each session sets up its own keyring.
s/session/service/ sorry. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c17 --- Comment #17 from Roger Whittaker <roger.whittaker@suse.com> --- In answer to comment#15 I can confirm that the problem that led to my original report ("ecryptfs-mount-private" failing when run remotely) is solved by the workaround of running "keyctl link @us @s" first. And running "keyctl link @us @s" before "ecryptfs-setup-private" also allows that command to work as expected. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c47 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #47 from Thorsten Kukuk <kukuk@suse.com> --- Commited to git. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1045886 http://bugzilla.suse.com/show_bug.cgi?id=1045886#c48 --- Comment #48 from Swamp Workflow Management <swamp@suse.de> --- This is an autogenerated message for OBS integration: This bug (1045886) was mentioned in https://build.opensuse.org/request/show/565816 Factory / pam-config -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1045886 https://bugzilla.suse.com/show_bug.cgi?id=1045886#c53 --- Comment #53 from Franck Bui <fbui@suse.com> --- (In reply to Franck Bui from comment #52)
In my understanding it was fixed by the disabling of the keyring stuff in systemd, but IMHO it should be a temporary workaround until the pam_keyinit is really included in the PAM stack.
To track the integration of pam_keyinit, I opened bug #1081947.
FYI I dropped the temporary workaround as bsc#1081947 has been addressed. My basic testing seems to indicate that the initial problem with ecryptfs+sshd (or login) is no more present and now user keyring is linked from session keyring. Hence next update of systemd will set up a private keyring for each system service. Please open a new bug report if you encounter a bug related to this change. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com