Re: Bug#996418: xrdp: sets hard-coded PATH for X11 session
Control: retitle -1 xrdp: sets hard-coded PATH for X11 session
Control: reassign -1 xrdp
[some lines in the quoted message have been reshuffled here to turn it
into a more concise bug report for xrdp; xrdp maintainers, please see
the original bug if more info is required]
On Wed, 13 Oct 2021 at 22:32:24 +0200, Thorsten Glaser wrote:
> dbus-update-activation-environment: sets wrong PATH since March 2021
>
> Hi, not sure which package is actually at fault here, but here we go.
> Please reassign (and notify the target package maintainers) as needed.
...
> I would have expected a user X11 session to use this:
> /etc/environment:PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
>
> Instead we're getting a PATH set that nowhere even is configured:
...
> dbus-update-activation-environment: setting PATH=/sbin:/bin:/usr/bin:/usr/local/bin
...
> This machine is a regular desktop but also has xrdp+xorgxrdp installed
> so I can use it while working remotely. The xrdp sessions log to
> ~/.xsession-errors which is where I could spot the first possible cause
> for this error.
You might be imagining that dbus-update-activation-environment is forcing
particular environment variables for your GUI session, but it's the other
way round: its purpose is to receive environment variables (usually from
your GUI session) and copy them to non-GUI processes elsewhere in the
process hierarchy (specifically, dbus-daemon's children).
If dbus-update-activation-environment is setting a PATH that you
consider to be wrong, then this is either misconfiguration, or a bug
in its caller. d-u-a-e is a mechanism rather than part of a policy:
it is not configurable, and does not hard-code a PATH itself.
> Specifically, the presence of /sbin without /usr/sbin in the "bad"
> PATH causes questions
That seemed odd to me too, and perhaps distinctive enough to identify
a root cause from. So I tried codesearch, with some adjustment to eliminate
false positives:
https://codesearch.debian.net/search?q=%5B%5Erl%5D%2Fsbin%3A%2Fbin%3A%2Fusr%2Fbin%3A%2Fusr%2Flocal%2Fbin&literal=0
and sure enough, the path you didn't want is hard-coded in xrdp:
g_setenv("PATH", "/sbin:/bin:/usr/bin:/usr/local/bin", 1);
I think the chain of events here is:
* xrdp sets this PATH
* nothing overwrites it with a value that is more to your liking
* Xsession inherits this PATH from xrdp
* /etc/X11/Xsession.d/95dbus_update-activation-env inherits this PATH
from Xsession
* dbus-update-activation-environment uploads it to dbus-daemon, while
logging a message
* /etc/X11/Xsession.d/99x11-common_start starts the "outermost" process
in your GUI session (whatever its equivalent of gnome-session is)
* your GUI programs also inherit this PATH
If xrdp is acting as a login entry point, then it's the equivalent of
a display manager like xdm/gdm/etc.; so I would have expected it to
invoke the PAM stack, including pam_env.so to read /etc/environment,
like display managers do.
smcv
Reply to: