recover dbus address when shadowing

[totaam]

Splitting from #2903.

Then when executing commands in that shadow server, they won't need to figure out the path to DBUS_SESSION_BUS_ADDRESS themselves.

[stdedos]

Comment #2903 (comment):

Is this to force authentication again when an xpra client connects?

bash -c xpra id "${DISPLAY}" | grep session-type= | cut -d = -f 2 | grep -qP "shadow" || exit 0 ; \
    env DBUS_SESSION_BUS_ADDRESS="$(cut -f 2- -d= "${XDG_RUNTIME_DIR}/dbus-session")" \
    gnome-screensaver -l

I assume that this a --start-on-connect?
Neat, we should make this a bit easier to use: #3110

No, this is a force-logout on disconnect for shadow monitors 😀 (and obviously it's --start-on-client-exit)
(Funny thing, manual has zit on --start-on-client-exit, but does on --start-on-last-client-exit)

If you have some idea on how to unlock-on-connect, it might be useful.
On Xenial, there was a [sudo] loginctl unlock-session <id:c2> command; however, that prohibited the "normal lockscreen use" (i.e. unlock the system by sitting in front of DISPLAY=:0) until the system was rebooted (or some other, more specific condition). Useful when the lockscreen was crashing, but ... otherwise no.

However, even if a contraption like that existed, I would be somewhat worried what might happen. If xpra manages to unlock the server, while failing to re-lock it on initialization error/loss of connectivity/"other error", it could lead to over-the-shoulder peeking or "unauthorized access".
This is the most sekur thing I could think of (and materialize) in 2-3 hours that I have spent on it that, barring a pkill -9 -f xpra, would successfully lock the Xenial monitor. (Not thoroughly tested/verified in Focal, but it is still there as you can see).

Since I have been working for more than a year exclusively remotely, and the fact that xpra gets better at handling seamless servers, the argument of "Shadow is better, because I can have 'one desktop' both remotely and physically" argument is both void (no real constant need for same experience) and has a lot of disadvantages, like excessive latency, maybe :0 (or :1 nowadays anyway) stays unlocked, and lack of "monitor-perfect" scaling (for the viewport and the bandwidth [?] #2052).

[totaam]

It seems that on Fedora 34, there are no X11 properties and no environment variables pointing to dbus.
All I have is a socket at $XDG_RUNTIME_DIR/bus that belongs to systemd / dbus-broker.
The man page points to dbus-broker-launch as being the new dbus-launch replacement.
The protocol must follow the socket-activation as defined by systemd.socket(1). Only a single socket is supported right now.

I'm going to stay away from this stuff.

[stdedos]

It seems that this hackery

Is this to force authentication again when an xpra client connects?

bash -c xpra id "${DISPLAY}" | grep session-type= | cut -d = -f 2 | grep -qP "shadow" || exit 0 ; \
    env DBUS_SESSION_BUS_ADDRESS="$(cut -f 2- -d= "${XDG_RUNTIME_DIR}/dbus-session")" \
    gnome-screensaver -l

(and related, also with xdg-screensaver lock) do not seem to work from outside the display itself for Ubuntu Focal 20.04 etc (last worked on Ubuntu Xenial 16.04).

Additionally:

• File ${XDG_RUNTIME_DIR}/dbus-session does not seem to exist in Ubuntu Focal.
• Socket source files in ~/.dbus/*/* do not seem to work if sourced (bash -c ". ~/.dbus/*/*; gnome-screensaver -l"; xdg-screensaver lock borks audibly)*
• Hacks like https://unix.stackexchange.com/a/642592/266638 don't work either

*: files/executions are of course sourced/done separately for each file; only description is abbreviated.

[totaam]

BTW, since we're now moving sessions to separate directories in #3217

It now looks like this for seamless sessions:

$ ls  /run/user/1000/xpra/10/
cmdline  config  dbus.env  dbus.pid  server.env  server.pid  xauthority  xvfb.pid

And for shadow sessions:

$ ls  /run/user/1000/xpra/1/
cmdline  config  server.env  server.pid  socket  tmp

But we could populate dbus.env (and skip dbus.pid to make sure we never kill it) for shadow sessions if only there was a reliable way of doing so.

[stdedos]

I won't have access to my current setup soon, and I am not sure if/when I will have a comparable need soon.

I could consider a related setup for my main Windows PC / Ubuntu dev laptop.

[stdedos]

And for shadow sessions:

$ ls  /run/user/1000/xpra/1/
cmdline  config  server.env  server.pid  socket  tmp

Thaaaat is not exactly accurate with my private installation:

u@h:/run/user/1000/xpra/0$ ls -h  
cmdline  config  dbus.env  dbus.pid  server.env  server.log  server.pid  tmp  xauthority
u@h:/run/user/1000/xpra/0$ tail -vn+1 dbus.*
==> dbus.env <==
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-8eT9JO4ADk,guid=ca6a3273e65d0d46f638512f617fe0eb
DBUS_SESSION_BUS_PID=580057%
==> dbus.pid <==
580057%

Launched as:

"Xpra-Python3-x86_64_4.3-r30322\xpra_cmd" shadow ssh://user@ip/0 --ssh="plink -ssh -agent" --modal-windows=no --desktop-scaling=no --headerbar=off --title="@title@ on @@/@server-display@" --microphone=off --speaker=off --webcam=no --pulseaudio=no

("my private installation": Ubuntu Focal 20.04 updated from 18.04.
The original linux server [i.e. the one I was always reporting bugs from] was using was an Ubuntu Focal 20.04, but updated from 16.04 [has some Ubuntu upgrade migration differences])