[systemd-devel] PAM session hooks for independent session

[Lennart Poettering]

On Sat, 29.10.16 18:37, Antoine Martin (antoine at 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:
> session    required     pam_localuser.so
> session    sufficient  	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