Re: Bug#996418: xrdp: sets hard-coded PATH for X11 session
Hi Simon,
>You might be imagining that dbus-update-activation-environment is forcing
>particular environment variables for your GUI session, but it's the other
yes, this is what I thought at first.
>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).
Ah, thanks for the added explanation.
>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:
Oh, codesearch isn’t something that occurred to me ☻
I did arrive at the same conclusion by tracing which processes had
that string in their environment and where it could have come from
in the meantime, though (see my second mail).
>* xrdp sets this PATH
>* nothing overwrites it with a value that is more to your liking
>* Xsession inherits this PATH from xrdp
Yes, exactly. And it’s the “nothing overwrites it” part that was
the bug, and I even figured out *that* as well (xrdp, in contrast
to e.g. su or kdm, doesn’t use pam_env).
>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.
Heh yeah. It is. And I’m nowhere even near a GUI expert, I figured
that out while debugging this issue and gave the possible fix a shot.
Great to hear it confirmed from someone who’s actually versed in the
entire modern desktop thing. (And a good learning experience.)
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Reply to: