'Twas brillig, and Haug B?rger at 16/12/10 20:44 did gyre and gimble: > Colin Guthrie schrieb: >> 'Twas brillig, and Haug B?rger at 13/12/10 20:37 did gyre and gimble: >> >>> Colin Guthrie schrieb: >>> >>>> 'Twas brillig, and Haug B?rger at 12/12/10 10:59 did gyre and gimble: >>>> >>>> >>>>> The leatest Ubuntu has a serious security bug caused by pulseaudio. If >>>>> you configure pammount to mount a crypted home directory it is not >>>>> able >>>>> to unmount it because pulseaudio has files in use (.pulse/*). You can >>>>> not even kill the daemon because it is set to user session. >>>>> >>>>> So, how can you stop the pulseaudio user session? In the hope that >>>>> this >>>>> releases the files. >>>>> >>>>> Is it really necessary for the deamon to lock the files that you >>>>> can not >>>>> unmount or is this a bug? >>>>> >>>> It's quite deliberate. PA has a timeout that prevents it from closing >>>> immediate. This means that if PA autospawns, it will stick around for a >>>> little while in case it's needed again (while startup is fairly quick, >>>> we do have to probe the hardware so it does take time). This is >>>> primarily for console applications rather than X11 however, as under >>>> X11 >>>> a Session Manager module is loaded which keeps PA alive for the >>>> duration >>>> of the X session. >>>> >>>> You can make a change in daemon.conf to set exit-idle-time to 0. This >>>> should allow PA to exit when the X11 session exits. >>>> >>> This doesn't work. Probably because you might have another user session >>> with X11 active. This means PA is not closed and gdm can not close the >>> session properly. >>> >> >> Do you mean you have two X11 sessions for the same user active? If so I >> don't understand why you'd want to unmount your $HOME in this case.... >> If you do not mean that there are two sessions by the same user active >> can you please explain this statement some more as I don't fully >> appreciate what your are describing. >> > I'm not sure, I'm not an X11 expert. What I do is I change the user within > Ubuntu. That keeps all my application open an gives me a login for another > user. I have multiple desktops open. I think that means I have multiple > X11 sessions. OK, so you log in as a different user in this case, not the same user for a second login. When this happens, your previous user session is still available but is no longer "Active" (see ck-list-sessions). I'm not sure what you'd expect here, but I certainly would not expect the home directory of the inactive session to be unmounted. Any number of things could still happen even when the session is inactive - Thunderbird could be collecting email, compilations could be progressing etc. Just because the X11 session is not active, it does not mean that everything stops. Only when you actually log out should your home directory be umounted, but this is a fast user switch which is quite different. I get the impression I'm still not fully understanding the problem here. I can understand that due to PA lasting longer than the X11 session that the umount of your home directory cannot happen, but that should only apply to a proper logout, not a fast user-switch. As I previously stated, the exit-idle-timeout should solve that issue. Is the users home directory really supposed to be unmounted when you are still technically logged in? >>> I don't care if PA still runs but why does it lock files in my home >>> directory? >>> >> >> Well it uses a socket file to communicate with other processes. This >> file is typically stored in $TMPDIR which is often $HOME/tmp. I suspect >> it is this socket file that is causing you problems. >> > No, there were several files open in the .pulse directory open. Possibly the database files used to store configuration etc. Hard to say unless you list them. >>> It is not even possible as root to shut down a user session. Gdm can not >>> even kill the user session. This makes PA a pain in the a... >>> >> Not really sure what you mean here? Root can easily kill any PA process. >> Can you describe what you mean in more detail here? >> > Yes you can kill it and it pops up again immediately. And again it locks > file > in my home directory. As root you can not shut down the PA session. The only reason it will pop up again is because some application is still running and requests that you start PA again - this is typically the sound applet in the systray or any Gnome application that uses libcanberra (technically all gtk apps in all likelihood) If you are logging out, then these apps should be terminated, but from your explanation above, I think you're expecting this to happen on user-switch too. Personally I'm not sure I agree that this can or should happen, but if so, then there would need to be code added to the various database implementations (assuming it was the database files that were locked) to release the locks when the session is suspended and reacquire them when it is restored. We would also have to re-read the data as someone may have modified it in the mean time while we were shut out. >>> So, how can you stop the pulseaudio user session? >>> >> >> A user can simply call "pulseaudio -k" will kill their PA session. >> However, depending on what other applications are still running, it may >> very well be autospawned again. >> > Yes but you have to be the user and the script runs as root. And root > wants to get rid of the user session. su user -c "pulseaudio -k" ? >> It would be very trivial to add a option to >> src/modules/x11/module-x11-xsmp.c in the kill_cb() that would shut down >> the PA daemon on X11 logout, but it is not currently done in order to >> ensure that multiple X11 sessions by one user are supported. I guess >> some smarts could allow for checking the loaded modules and only exit if >> no other x11-xmsp module instances exist. >> > I'm not sure what the term session means in the X11 context but, > usually you open a session A, maybe a session B and then you close e.g. A. > What has that to do with the user? Usually a session is something like a > handle and you use it to have multiple. If I logout one X11 session, why > should that close another session? It shouldn't kill the other session. That's why I specifically mentioned that it would need to check for other instances of module-x11-xsmp so as not to exit when multiple sessions are active. I'm not really sure if this applies in your case however, as I suspect in the example above Session A is for a different user to Session B. If this is the case then they will run their own, completely separate PA daemons. PA is a per-user daemon (at least that's our recommendation). A single user can open multiple X11 sessions, but they will still only have one PA daemon. Or multiple users can open one X11 sessions each, and they will each get their own PA daemon. The PA daemon of one user does not communicate in any way with the PA of another user. When talking about multiple sessions in examples, please clarify the user of that session so we can discuss things in the right context :D >> I'm still not 100% sure why this whole thing is a problem tho'. I'm sure >> there is an easy way to kill all processes started by a user - this will >> certainly be especially true/easier when systemd handles user sessions: >> > I tried to use the gdm post session script to force unmount. > I tried to kill it and it pops up again immediately. What script is this? Would this not be triggered at logout rather than session suspend? If it's getting triggered at session suspend, then I expect something is not right there. A post-session script should only really be run when the session is ending. Perhaps some other application is still running at this stage that is not yet killed and it re-launches the PA daemon? > The problem is that PA prevents pam mount to unmount your crypted > home directory. It stays open, even after logout and there is no trigger > to close it. This makes all the crypting a useless. Again, are you really talking about when the session ends, or when it is suspended? I'm sure that if you log out (not just suspend the session), unless it's some other application that is starting PA again, that this process should work fine. I'd investigate what other PA applications are running and requesting autospawn here. Try killing off any applets or agents that are unnecessary. You may also wish to ask some Ubuntu specific channels/forums too as they do provide their own PA control systems that are not provided by us upstream, and it is conceivable that it is these additions that are respawning PA. > All I want is to properly close a session previously opened at login. > Neither > gdm nor myself are able to do that. >> http://0pointer.de/blog/projects/systemd-update-2.html >> "We now safely destroy all user session before going down. This is a >> feature long missing on Linux: since user processes were not killed >> until the very last moment the unhealthy situation that user code was >> running at a time where no other daemon was remaining was a normal part >> of shutdown." >> >> > That's nice but I do not shut down every time. systemd will eventually handle user sessions too. It's not just about boot/shutdown. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
