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: RESOLVED NOTOURBUG
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high 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: 2019-08-19 13:25 UTC (History)
5 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.
Comment 3 Daniel Ziltener 2019-02-11 12:33:25 UTC
I can't believe it. It's 2019 and this bug is still not fixed. Why exactly is RedHat still paying your salary?
Comment 4 Lennart Poettering 2019-02-11 16:48:41 UTC
> I can't believe it. It's 2019 and this bug is still not fixed. Why exactly is RedHat still paying your salary?

I understand this bug report is important to you. It's not really high up on my list however, and to my knowledge my employer never supported ecryptfs, hence both to me and my employer this bug isn't of particular importance.

If you require this issue to be fixed, please consider filing a support request to the distribution of your choice that supports ecryptfs, and I am sure they'll help you, and make sure the bug is fixed and the bugfix contributed upstream.

Other than that, I doubt anything will change about this issue any time soon.
Comment 5 Lennart Poettering 2019-08-19 13:25:29 UTC
So, let's close this. This needs to be fixed by ecryptfs. The user@.service instance (i.e. systemd's --user instance) runs through the PAM session hooks like any other PAM session, hence if ecryptfs properly unmounts its home directory when the last PAM session of the user dies, then all should work, correctly.

Note that for performance reasons the --user instance sticks around for a bit longer after the user logged out completely, but that should be OK, the PAM session exit hook is called when it exits, and that should be all that ecryptfs needs to umount things.

Hence, closing.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.