Encrypted home directory doesn't unmount, Pulseaudio the culprit?

On my laptop, I have successfully set up an encrypted home directory for my user, using Yast. The process took a while (it was an already filled home directory) but completed without errors. After reboot, I could log in successfully, my home directory and all files were present as expected (okay, hoped).

The problem is that when I log out of the system, normal behaviour is for the encrypted home directory to be automatically dismounted. This however, does not happen. The files remain accessible after log out by any user who happens to be in the “users” group, which is everyone by default.

I did some checking and found the following errors in /var/log/messages:

 2013-06-11T10:22:51.836231+02:00 orthanc kdm: :0[2341]: pam_unix(xdm:session): session closed for user joopberis
 2013-06-11T10:22:51.950746+02:00 orthanc kdm: :0[2341]: (mount.c:68): umount messages:
 2013-06-11T10:22:51.952731+02:00 orthanc kdm: :0[2341]: (mount.c:72): NOTE: mount.crypt does not support utab (systems with no mtab or read-only mtab) yet. This means that you will temporarily need to call umount.crypt(8) rather than umount(8) to get crypto volumes unmounted.
 2013-06-11T10:22:51.991026+02:00 orthanc kdm: :0[2341]: (mount.c:72): **umount: /home/joopberis: target is busy.**

 2013-06-11T10:22:51.991717+02:00 orthanc kdm: :0[2341]: (mount.c:72):         (In some cases useful info about processes that use

 2013-06-11T10:22:51.991730+02:00 orthanc kdm: :0[2341]: (mount.c:72):          the device is found by lsof(8) or fuser(1))
 2013-06-11T10:22:51.992030+02:00 orthanc kdm: :0[2341]: (mount.c:72): umount /home/joopberis failed with run_sync status 2
 2013-06-11T10:22:56.797444+02:00 orthanc kdm: :0[2341]: (mount.c:872): unmount of /home/joopberis.img failed


Obviously, something is keeping some files open in my home directory, so it can’t be unmounted when I log out. From a virtual terminal, I logged in as root and checked if I could find the culprit.

# fuser -v /home/joopberis
                     USER        PID ACCESS COMMAND
/home/joopberis:     root     kernel mount /home/joopberis
                             joopberis   3369 f.... pulseaudio

It appears Pulseaudio is keeping a lock on some files. However, running fuser -v again a few moments later, the Pulseaudio process is gone.
The unencrypted home directory is left hanging around until the laptop is rebooted, which could be a security risk, since the user would expect his/her home directory to be unmounted and encrypted after log out.

My question is, how can I find out what causes Pulseaudio to wait before shutting down?
Or, how can I set up encrypted home directories in another, simple way, that avoids this problem?

I always prevent pulseaudio from installing or delete it after installation. Unless I’m wrong, you only need it for networked sound. Amarok, kaffeine etc work fine without it and it has caused me a few annoying problems on my desktop PC (eg. quite a few seconds delay in booting).

I suppose I could remove Pulseaudio, I don’t think I have any real need for it. However, I would rather get to the root cause of this, see if I can find out what is going wrong with the shutting down of Pulseaudio itself. That would hopefully make simply logging out safe again for users who have this problem and aren’t aware of it.

On 2013-06-11 12:36, petermcph wrote:
>
> I always prevent pulseaudio from installing or delete it after
> installation. Unless I’m wrong, you only need it for networked sound.

Wrong :slight_smile:

It is needed, for example, so that two applications can generate sound
at the same time and do not block one another. True, some hardware can
do this without pulse, but not all. I could not.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-06-11 11:36, joopberis wrote:

> The problem is that when I log out of the system, normal behaviour is
> for the encrypted home directory to be automatically dismounted. This
> however, does not happen. The files remain accessible after log out by
> any user who happens to be in the “users” group, which is everyone by
> default.

Well, create a group named after your user name, and assign your user to
that group. Then, change group ownership of your entire home. You will
have to ensure that the permissions for “others” are nil. You may want
to change the default mask.

You should do this even if you solve the umounting problem.

> Obviously, something is keeping some files open in my home directory,
> so it can’t be unmounted when I log out. From a virtual terminal, I
> logged in as root and checked if I could find the culprit.

Pulseaudio delays in dying, I know.
What openSUSE version are you using? You did not say.

> My question is, how can I find out what causes Pulseaudio to wait
> before shutting down?

→ Bugzilla, if the answer to my question is 12.3 or factory.

> Or, how can I set up encrypted home directories in another, simple way,
> that avoids this problem?

Not simpler. You can activate the partition manually, as root, log in as
user, log out, umount manually. Hardly simpler :slight_smile:

You might, however, hook up a script to session logout to run something
in, say, 3 minutes (‘at’ command) to umount the user’s home, and to
disable that encrypted holder.

I do not know where exactly to hook that script.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Yes, I am planning to do that anyway.

Pulseaudio delays in dying, I know.
What openSUSE version are you using? You did not say.

I am on 12.3, just updated my signature to reflect that. Been a while since I was on openSUSE. :slight_smile:

→ Bugzilla, if the answer to my question is 12.3 or factory.

Yes, Bugzilla might be the way to go. Sounds like a bug to me, since this is a fairly vanilla system.

https://bugzilla.novell.com/show_bug.cgi?id=824381

On 2013-06-11 14:46, joopberis wrote:
> robin_listas;2564061 Wrote:

>> You should do this even if you solve the umounting problem.
>
> Yes, I am planning to do that anyway.

Good :slight_smile:

>> What openSUSE version are you using? You did not say.
>
> I am on 12.3, just updated my signature to reflect that. Been a while
> since I was on openSUSE. :slight_smile:

Signatures can not be relied on for this data. Reasons? That when you
upgrade to 13.1, for instance, and you change your signature to reflect
that, all posts, even those you made 5 years ago, say that you were
using 12.3 five years before it was released - thus you are a time
traveler and you need not asking questions: just travel to the future
and get openSUSE 200 :-p

That on the web side… on my nntp I see you sig on the current post,
but not the old one. Posts do not change once sent.

>> → Bugzilla, if the answer to my question is 12.3 or factory.
>
> Yes, Bugzilla might be the way to go. Sounds like a bug to me, since
> this is a fairly vanilla system.

Yes, but it might not be solved in years, so you need to look at the
trick I told you.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Rather heavy-weight would be adding kill-session-processes=1 to pam_systemd (see man pam_systemd).

Otherwise you may try to add “load-module module-x11-xsmp” to your personal default.pa. In this case X shutdown should also kill pulseaudio server.

When I try that link, it says I am not authorized to see the bug. I’m not sure what’s the point of posting a link to a private bug report. (And, yes, I am currently logged into bugzilla).

Filing a but about a security component (which I believe this is), the bug gets marked private. That’s not something that I can change, I didn’t mark it private. The link is there to inform people who read this thread that a bugreport has been filed. Should someone have the same issue, they don’t need to report it again.

Thank you, I’ll give that a try and let you know what it does.

On 2013-06-11 18:06, arvidjaar wrote:

> Rather heavy-weight would be adding kill-session-processes=1 to
> pam_systemd (see man pam_systemd).

If it does a kill 9, it would be rather heavy. If it is a plain kill 15,
it would be alright. I actually have a script to kill services from a
user text session:

cer@Telcontar:~> cat /home/cer/bin/matar_restantes
#!/bin/bash
ps afxu | grep cer
echo


pulseaudio --kill
killall beagled
killall knotify4
killall gnome-panel
killall gweather-applet-2
killall bonobo-activation-server
killall gpk-update-icon
killall gnome-keyring-daemon

echo
ps afxu | grep cer
cer@Telcontar:~>

As you see, pulse can be easily and politely killed. You just need to
call “pulseaudio --kill” when logging out - the question is: how?


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-06-11 22:16, joopberis wrote:

> Filing a but about a security component (which I believe this is), the
> bug gets marked private. That’s not something that I can change,

Yes you can. Actually, you are the only one that can do it, besides some
SUSE employees,

> I
> didn’t mark it private.

You left the box ticked. YOu could have unticked it. I usually do.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Actually it should send SIGTERM first and use SIGKILL only as last resort. May be pulseaudio takes too much time to shut down.

You just need to
call “pulseaudio --kill” when logging out - the question is: how?

That’s the question for your desktop environment.

On 2013-06-12 05:16, arvidjaar wrote:
> robin_listas;2564156 Wrote:

> Actually it should send SIGTERM first and use SIGKILL only as last
> resort. May be pulseaudio takes too much time to shut down.

Maybe it is intentional, because calling “pulseaudio --kill” kills it
politely and fast. I think that it is left running in case you log in
again, or perhaps somebody else logs in.

>> You just need to
>> call “pulseaudio --kill” when logging out - the question is: how?
> That’s the question for your desktop environment.

Of course, but I would like to know. I don’t need it (not now, at
least), but I would like to know.

Or maybe the process that tries to umount home could try that call.
maybe it has a hook script.

I believe there is a kde autostart folder. Or gnome. Dunno about one for
all desktops. Dunno about an autostop folder.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Actually here on pristine 12.3 GNOME + patches pulseaudio already loads xsmp module, gets notification about X server going away and terminates. But it takes about 20 seconds from connection to X server being lost and pulseaudio shutdown.

Me too (not specifically for pulseaudio). If you ever find how to do it for GNOME3, let us know :slight_smile: Apparently GNOME3 deliberately removes all possibilities for end user to adjust its behavior, or at least hides it very deep.

On 2013-06-12 13:36, arvidjaar wrote:
> robin_listas;2564236 Wrote:

>> Of course, but I would like to know.
>
> Me too (not specifically for pulseaudio). If you ever find how to do it
> for GNOME3, let us know :slight_smile: Apparently GNOME3 deliberately removes all
> possibilities for end user to adjust its behavior, or at least hides it
> very deep.

I no longer use gnome. I was a heavy gnome 2 user, but I dislike G3. I
use now xfce.

I see:

/home/cer/.config/autostart
/home/cer/.kde4/Autostart
/home/cer/.kde/Autostart

I don’t see a closure related folder under “/home/cer/.config/”, though.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)