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: > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
