xpra shadow :0 fails to connect to X server before user logs into X session :0

[basilgello]

I recall I tested this before, but I doubt I did xpra shadow right after system restart.

Issue is, Xsession adds the user currently logged to xauth authorization list. So xpra shadow :0 run as uid 1000 works with uid 1000's MIT-X-Cookie. However, when Xpra remote client asks the Xpra proxy server to start Xpra shadow server under the uid who is not logged into X session at the moment (i.e not in xauth list), Xpra shadow server fails to connect Xvfb to :0 and exits dirty, and remote client times out.

I am not sure how to handle this issue securely. I guess, when user authentication is complete, we need to check if Xpra shadow can attach to X0. If user can not attach, and user is in video group and no other user is logged into target X server session, Xpra must steal the lightdm cookie from /var/lib/lightm and pass it to Xvfb running under user nobody (not root or target user because this can lead to cookie exposure).

@totaam ?

[totaam]

IIRC, the key problem here is finding the correct $XAUTHORITY to use. We do try to add ourselves to this file: https://github.com/Xpra-org/xpra/blob/8fe130a3c6ed70d32d298ce386c3a0c2856bf1fb/xpra/scripts/server.py#L985-L1011

Perhaps adding or shadowing to this code block would be enough?

[basilgello]

Perhaps adding or shadowing to this code block would be enough?

Let me try :)

No, does not work. Let me figure out how do I check the correct XAUTHORITY then.

[totaam]

Did you figure out which XAUTHORITY to use to make this work?

[basilgello]

Yes! I will need to doing a PoC. The only reliable way is to get pid of process serving the socket and parse its cmdline to get path to xauthority file…

[totaam]

@basilgello And the answer was? XAUTHORITY=???

[basilgello]

@totaam /var/run/lightdm/Xauthority-root. But let me explain the detectiin logic or PR it next morning

[totaam]

Bump