[systemd-bugs] [Bug 72759] New: Systemd user manager interferes with ecryptfs - private directory not being unmounted
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Dec 16 07:32:14 PST 2013
https://bugs.freedesktop.org/show_bug.cgi?id=72759
Priority: medium
Bug ID: 72759
Assignee: systemd-bugs at lists.freedesktop.org
Summary: Systemd user manager interferes with ecryptfs -
private directory not being unmounted
QA Contact: systemd-bugs at lists.freedesktop.org
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: rickert at ameritech.net
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: general
Product: systemd
This is observed with opensuse 13.1, using an ecryptfs private directory. On
one computer, I am using an encrypted home directory with ecryptfs.
On logout, the private directory remains mounted (so visible decrypted). I see
this as a security concern.
If I remove systemd from the pam configuration, the ecryptfs reverts to working
as it should.
Example: on my work computer, I use an encrypted home directory.
I logout when I leave work.
A remote login from home (ssh with public key authentication) shows that the
encrypted home directory is still mounted.
The command "ecryptfs-umount-private" tells me that the directory is mounted in
another session. Repeating "ecryptfs-umount-private" does unmount it.
Thereafter, ecryptfs works properly until the next boot.
I tried "systemctl --user exit" in a KDE exit script. That shuts down the user
manager process, but it does not fix the problem with the ecryptfs private
directory remaining mounted.
My best guess is that the systemd is creating an additional pam session for
this user, and never exiting that session. And this throws of the session
counting by the ecryptfs pam module.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20131216/bd5a65d8/attachment.html>
More information about the systemd-bugs
mailing list