Mass bug filing: use and misuse of dbus-launch (dbus-x11)
XDG Base Directory Specification:
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
Simon McVittie:
Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client
libraries should choose some arbitrary other directory that is
conjectured to have the same properties that the XDG_RUNTIME_DIR spec
guarantees, look for a ./bus socket in *that* directory [...]?
Simon McVittie:
Using the same concrete value for the name of the XDG_RUNTIME_DIR that
systemd does (/run/user/$numeric_uid) seems advisable, [...]
These two fit together, you know.
You think that a good "replacement directory" is /run/user/$EUID .
Alright. Then when your program is told address=unix:runtime=yes and
there's no XDG_RUNTIME_DIR, please make it fall back to using the
directory that you think is the advisable directory to use. (-:
At the moment, as far as I can see, when there's no XDG_RUNTIME_DIR
there's no fallback per the XDG specification at all. We all know that
XDG_RUNTIME_DIR has been a thorn in people's sides for years, where
there is a mismatch between the owner of the runtime directory and the
process' effective user. The irony is that you and your program would
get quite sensible behaviour without it, were you to make
address=unix:runtime=yes actually do the thing that you are here saying
is advisable. In the cases where address=unix:runtime=yes is used, and
when they are all doing what you say is advisable, your servers set up
their sockets in {/var,}/run/user/$UID/dbus_blah and your clients go
looking for those sockets in the same place, picking the right one for
the process' effective UID and rendezvousing in the right place.
And the people who still want XDG_RUNTIME_DIR still get to have it, and
all of its do-we-or-do-we-not-follow-euid-changes-maybe-sometimes joy
that the world has come to know and love.
This as well as having made address=unix:runtime=yes actually work in
the first place, of course. (-:
Reply to: