tianon/gosu

Missing LD_LIBRARY_PATH variable problem

xfoobar opened this issue · 7 comments

Version:1.13
The LD_LIBRARY_PATH variable will be lost after executing gosu.

Example:
test.sh

export LD_LIBRARY_PATH=/tmp
export ABC=123
gosu foobar env

output:

PWD=/tmp
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ABC=123
OLDPWD=/
_=/usr/sbin/gosu
HOME=/home/foobar

Interesting, although I'm not able to reproduce? Maybe there's something more to how you're using it (or how it was built) that's causing this behavior? Any more details you can provide?

$ sudo env -i LD_LIBRARY_PATH=/tmp ./gosu-amd64 0:0 /usr/bin/env
LD_LIBRARY_PATH=/tmp
HOME=/root

Interesting, although I'm not able to reproduce? Maybe there's something more to how you're using it (or how it was built) that's causing this behavior? Any more details you can provide?

$ sudo env -i LD_LIBRARY_PATH=/tmp ./gosu-amd64 0:0 /usr/bin/env
LD_LIBRARY_PATH=/tmp
HOME=/root

before I test:

# login as root
# allow normal users to use gosu
chmod a+s /usr/local/sbin/gosu
# switch to a normal user
su - normal_user
# execute test script
./test.sh

Whoa, full stop. Please do not ever set the sticky bit on gosu -- you might as well just install sudo and give every potential user on the entire system passwordless access.

Whoa, full stop. Please do not ever set the sticky bit on gosu -- you might as well just install sudo and give every potential user on the entire system passwordless access.

Well, I actually want to switch to any user (include root) when using PODMAN_USERNS=keep-id in the podman container , sudo cannot be used because the user name and uid at the time of execution cannot be predicted, could you give me some other suggestions? Thanks.

Honestly feels a bit like https://xyproblem.info/ -- what is it you're actually trying to accomplish? What's the underlying problem you're hoping to solve?

Thanks, I solved this problem by configuring ldconfig.

I guess https://unix.stackexchange.com/a/48549/153467 explains why the variable gets stripped (it's not something we can fix -- it's inherent to setuid binaries).