[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
http://bugzilla.suse.com/show_bug.cgi?id=1045886
http://bugzilla.suse.com/show_bug.cgi?id=1045886#c2
Andrei Borzenkov
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
http://bugzilla.suse.com/show_bug.cgi?id=1045886
Chenzi Cao
http://bugzilla.suse.com/show_bug.cgi?id=1045886
http://bugzilla.suse.com/show_bug.cgi?id=1045886#c4
--- Comment #4 from Roger Whittaker
http://bugzilla.suse.com/show_bug.cgi?id=1045886
http://bugzilla.suse.com/show_bug.cgi?id=1045886#c6
--- Comment #6 from Andrei Borzenkov
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
http://bugzilla.suse.com/show_bug.cgi?id=1045886
http://bugzilla.suse.com/show_bug.cgi?id=1045886#c7
--- Comment #7 from Andrei Borzenkov
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
http://bugzilla.suse.com/show_bug.cgi?id=1045886
http://bugzilla.suse.com/show_bug.cgi?id=1045886#c47
Thorsten Kukuk
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
https://bugzilla.suse.com/show_bug.cgi?id=1045886
https://bugzilla.suse.com/show_bug.cgi?id=1045886#c53
--- Comment #53 from Franck Bui
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