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
