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

2016-11-03 Thread Lennart Poettering
On Sat, 29.10.16 18:37, Antoine Martin (anto...@nagafix.co.uk) wrote:

> 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:

You should not set the vtnr or seat name, if you are fully virtual and
do not manage local hw or local vts.

> [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.

Registering sessions requires privileges. If you want unprivileged
clients to be able to do this, you need to add a security transition
somewhere. This means your tool can either be SUID (which I wouldn't
recommend) or you split your tool in two: a tiny (socket activated)
daemon that does little else than wait for a client request, and when
it gets it, registers the PAM session and drops privs and runs your
virtual display server. Basically what a display manager such as gdm
does, but instead of managing physical seats you'd just instantiate a
virtual x server for each incoming connection.

Ultimately this is the best idea anyway, as you should properly
disconnect the new bg session from the original session, and that
means you should not have a process relationship between your
processes.

Hope this makes sense=

Lennart

-- 
Lennart Poettering, Red Hat
___
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 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