Re: [systemd-devel] PAM session hooks for independent session

2016-10-29 Thread Antoine Martin 
On 29/10/16 22:20, Brian Kroth wrote:
> On Sat, Oct 29, 2016, 07:02 Reindl Harald  > wrote:
> Am 29.10.2016 um 13:37 schrieb Antoine Martin:
> > Just like "screen" or "tmux", we want to ensure that some xpra
> sessions
> > (aka "screen for X11", VNC-like but seamless) can survive when the
> user
> > logs out
> 
> which is not longer true
> 
> https://www.reddit.com/r/linux/comments/4lebbr/systemd_to_kill_all_user_processes_after_logout/
Our need to manage user sessions will remain "true", I assure you.

> To be fair though, that was just a change in the default behavior. One
> can still disable that functionality in a couple of different ways
> (system wide via system.conf, per user "linger" setting, etc.) if they
> don't like it.
Maybe I should have been clearer, my original message includes technical
questions about implementing session management via pam_systemd and logind.
We are aware of linger, etc - these are not directly related to this
problem. Killing user processes at the end of the user session is by
design, we understand that and we want to participate in this session
management to ensure it does the right thing with our user sessions.

Cheers
Antoine


> 
> Cheers,
> Brian
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] PAM session hooks for independent session

2016-10-29 Thread Brian Kroth 
On Sat, Oct 29, 2016, 07:02 Reindl Harald  wrote:

>
>
> Am 29.10.2016 um 13:37 schrieb Antoine Martin:
> > Just like "screen" or "tmux", we want to ensure that some xpra sessions
> > (aka "screen for X11", VNC-like but seamless) can survive when the user
> > logs out
>
> which is not longer true
>
> https://www.reddit.com/r/linux/comments/4lebbr/systemd_to_kill_all_user_processes_after_logout/


To be fair though, that was just a change in the default behavior. One can
still disable that functionality in a couple of different ways (system wide
via system.conf, per user "linger" setting, etc.) if they don't like it.

Cheers,
Brian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] PAM session hooks for independent session

2016-10-29 Thread Reindl Harald 



Am 29.10.2016 um 13:37 schrieb Antoine Martin:

Just like "screen" or "tmux", we want to ensure that some xpra sessions
(aka "screen for X11", VNC-like but seamless) can survive when the user
logs out


which is not longer true
https://www.reddit.com/r/linux/comments/4lebbr/systemd_to_kill_all_user_processes_after_logout/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] PAM session hooks for independent session

2016-10-29 Thread Antoine Martin 
Hi,

Just like "screen" or "tmux", we want to ensure that some xpra sessions
(aka "screen for X11", VNC-like but seamless) can survive when the user
logs out.

Background: xpra runs X11 applications using an Xvfb server, when
client(s) are connected we forward the pixels/keyboard/mouse/etc.

Based on the info from this old post "[systemd-devel] tmux / screen":
https://lists.freedesktop.org/archives/systemd-devel/2011-June/002624.html
my understanding is that we may need both of these things:
* wrap our server startup with "systemd-run --scope --user"
* get the server to open a new logind session via pam

The "systemd-run" wrapping was easy enough, though it does seem to
actually make things worse:
* long ssh login delays afterwards - probably because of this bug:
https://github.com/systemd/systemd/issues/2863
* sessions get killed in circumstances where they did not prior to this
change - probably because the whole cgroup containing the daemon gets
taken down.

The pam_systemd is much more difficult to figure out, since I am not
aware of any other packages does this at present - maybe there are?
* should we ship a /etc/pam/d/xpra file like this one:
sessionrequired pam_localuser.so
sessionsufficient   pam_systemd.so class=user type=x11 debug=1
* we supply VTNR=0 (we don't have a VT..), XDG_SESSION_TYPE=x11,
XDG_SEAT=0 (not sure this is right) as well as the correct PAM_XDISPLAY
for the display we've started. But the pam_open_session call fails with:
pam_systemd(xpra:session): Failed to create session: Access denied
Probably because of this:
[system] Rejected send message, 2 matched rules; type="method_call",
sender=":1.339" (uid=1001 pid=15738 comm="/bin/python /usr/bin/xpra
start --systemd-run=yes "
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
interface="org.freedesktop.login1.Manager" member="CreateSession" error
name="(unset)" requested_reply="0" destination="org.freedesktop.login1"
(uid=0 pid=1185 comm="/usr/lib/systemd/systemd-logind "
label="system_u:system_r:systemd_logind_t:s0")

Where / how can we change the policy to allow sufficiently privileged
users to create a new session? (which users will get this privilege and
how this is configured is not entirely clear at this point - can we
somehow keep this simple using unix group permissions?)
How is this going to ensure that the cgroup is correct? Isn't that set
when the process is started?

Any help or pointers would be much appreciated.

Cheers
Antoine
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel