Bug 72759 - Systemd user manager interferes with ecryptfs - private directory not being unmounted
Summary: Systemd user manager interferes with ecryptfs - private directory not being u...
Status: REOPENED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-16 15:32 UTC by Neil Rickert
Modified: 2016-06-21 19:45 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Neil Rickert 2013-12-16 15:32:14 UTC
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.
Comment 1 Lennart Poettering 2014-02-21 17:12:08 UTC
systemd is not in the business of unmounting home directories.
Comment 2 W Unruh 2014-11-28 23:43:54 UTC
The answer referred to the symptoms, not the bug. The bug is that systemd leaves
something about the user "logged in" even after the user logs out. Thus in my 
system the SYMPTOM is that when I try to run reboot as user after I have logged out as root, I get an error message saying that user root is still logged in and this blocks the reboot. 
Another symptom is that systemd --user and (sd-pam) are left running for that logged out user even after that user (in my case aboove root) has logged out. 

So running in runlevel 3 on Mageia 4.1 newly updated, if I first log in as root
immediately log out as root (so I get another login request on the runlevel 3 terminal) and log in as unruh ( user 500) and then try to run reboot, I get an error message from systemd saying

User root is logged in on tty1
Please retry operation after closing inhibitors and logging out other users. 

The other users ARE logged out. 

As another SYMPTOM, if I log in as user, run poweroff or reboot, I get, after a number of messages, a timeout of 90 sec on User Manager failing. 90 sec completely defeats the stated purpose of systemd to speed up boots and halts.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.