« first day (804 days earlier)      last day (1763 days later) » 

03:01
@EliahKagan it's a pleasure, thanks for involving me :) :)
@EliahKagan cool! So the omission in my answer is not actually embarrassing!
At least, not too terribly
And it can be updated nicely
 
11 hours later…
13:54
@Zanna I had thought this form of --preserve-env might work for LD_ variables, too, but I think it does not.
14:05
oh hmm I didn't realise there was a special sudo thing with those variables
I don't think there is.
I think the dynamic loader unsets LD_PRELOAD when a dynamically linked setuid executable is run by a user who is not its owner.
14:24
This seems to happen even when the user running it is the owner.
Also, it seems not to be the dynamic loader that is doing it.
 
1 hour later…
15:30
@Zanna It is the dynamic loader.
I was thrown off by how the specific statically linked binary I tried (/bin/busybox) implements its own logic to unset LD_PRELOAD under some circumstances.
ek@Cord:~$ cp /usr/bin/printenv .
ek@Cord:~$ LD_PRELOAD=/lib/x86_64-linux-gnu/libc.so.6 ./printenv LD_PRELOAD
/lib/x86_64-linux-gnu/libc.so.6
ek@Cord:~$ chmod u+s printenv
ek@Cord:~$ LD_PRELOAD=/lib/x86_64-linux-gnu/libc.so.6 ./printenv LD_PRELOAD
ek@Cord:~$
But --preserve-env=list does work to preserve variables that sudo sets even with -E. This appears broadly to be the case, and not to be specific to the semi-undocumented case of PATH. For example:
ek@Cord:~$ SUDO_USER='Owls rule!' sudo -E printenv SUDO_USER
ek
ek@Cord:~$ SUDO_USER='Owls rule!' sudo --preserve-env=SUDO_USER printenv SUDO_USER
Owls rule!
hahaha
But it's because sudo is a setuid executable that LD_PRELOAD is removed from its environment before it actually runs. (sudo doesn't have a choice about that, except in the sense that it could have been provided as a statically linked executable instead.)

« first day (804 days earlier)      last day (1763 days later) »