Join Log in
Score:0
pfo avatar Ubuntu

Different output for ldd between sudo and root

cn flag
pfo

on my system, the output for ldd /usr/bin/openssl differers between the regular user, root and sudo.

This is the output for the regular user:

$ whoami
myname
$ ldd /usr/bin/openssl
    linux-vdso.so.1 (0x00007fff5bdd0000)
    libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f609a783000)
    libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f609a4a8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f609a271000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f609a8db000)

This is the output for the regular user sudo-ing into root:

$ sudo whoami
root
$ sudo ldd /usr/bin/openssl
    linux-vdso.so.1 (0x00007ffc5d75a000)
    libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4092062000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f4091ba6000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f409197e000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4091979000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4091974000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f40923bc000)

This is the output for root:

$ sudo su
$ whoami
root
$ ldd /usr/bin/openssl
    linux-vdso.so.1 (0x00007ffcccffe000)
    libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f4915593000)
    libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f49152b8000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4915081000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f49156eb000)

This is the output for the regular user sudo-ing into the bind9 user:

$ sudo -u bind whoami
bind
$ sudo -u bind ldd /usr/bin/openssl
    linux-vdso.so.1 (0x00007ffdcabb2000)
    libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f53973d4000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f5396f18000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5396cf0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5396ceb000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5396ce6000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f539772e000)

I'd like sudo to yield the same result that the regular user and root already have. How can I do this?

LD_LIBRARY_PATH is not identical among the environments, but I do not know how to make the values identical.

$ echo $LD_LIBRARY_PATH
/usr/lib/x86_64-linux-gnu
$
$ sudo bash -c 'echo $LD_LIBRARY_PATH'

$
$ sudo su
$ echo $LD_LIBRARY_PATH
/usr/lib/x86_64-linux-gnu
$
$ sudo -u bind bash -c 'echo $LD_LIBRARY_PATH'

$

I believe that the answer to this will solve this bind-related question.

141
0 + 0
waltinator avatar
it flag
waltinator
Read `man ldconfig`. The `LD_LIBRARY_PATH` environment variable probably differs among the different environments.
1
Reply
pfo avatar
cn flag
pfo
@waltinator: Thank you for your comment. `LD_LIBRARY_PATH` is actually identical among the environments, I added the output to the question.
0
Reply
Tilman avatar
cn flag
Tilman
The command `sudo echo $LD_LIBRARY_PATH` does not do what you seem to think. It actually outputs the value of `LD_LIBRARY_PATH` *outside* `sudo` because the shell performs the variable substitution before running the `sudo` command. Try something like `sudo bash -c 'echo $LD_LIBRARY_PATH'`.
3
Reply
waltinator avatar
it flag
waltinator
You did not check `$LD_LIBRARY_PATH` in different environments. Every time you typed "`$LD_LIBRARY_PATH`" (except for the `sudo su` case) it was filled in from your current environment, before command execution. See it happen by putting `echo ` before each of your 1-liners. `bash` evaluates environment variables early. Escape the `$` by putting a backslash ("`\ `") before it to delay evaluation, e.g. `sudo echo \$LD_LIBRARY_PATH`.
1
Reply
pfo avatar
cn flag
pfo
Thank you to both of you! You were right, the values were different indeed. `sudo bash -c 'echo $LD_LIBRARY_PATH'` yields an empty line. My next question is how I can fix this. I tried `sudo bash -c 'export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu'`, but of course the value is not stored and `sudo bash -c 'echo $LD_LIBRARY_PATH'` yields an empty line again.
0
Reply
Tilman avatar
cn flag
Tilman
You could try putting the `export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu` command into user `bind`'s `.bashrc` file but I doubt this avenue will lead you in the right direction. It looks like you have two different versions of `libssl.so.1.1` installed, one in `/lib/x86_64-linux-gnu` and one in `/usr/lib/x86_64-linux-gnu`. That's bound to cause problems. Try fixing that instead. Find out which one is the right one and lose the extra one.
1
Reply
pfo avatar
cn flag
pfo
@Tilman Thank you! Can I just run `rm /lib/x86_64-linux-gnu/libssl.so.1.1` or is there a "safer" way to do this? I'm afraid of ending up in an(other) inconsistent state.
0
Reply
Tilman avatar
cn flag
Tilman
The safest way would be to find out where the extra version came from, and depending on the result decide whether it is still needed. For example, if it was installed as part of some third-party software package you may want to keep a backup copy until you verified that the package also works with the version in `/usr/lib/x86_64-linux-gnu`.
1
Reply
Score:0
pfo avatar Ubuntu
cn flag
pfo

It turns out that the problem was that I had two different versions of certain libraries installed, which caused OpenSSL to behave differently depending on whether the user was using sudo or not.

Removing those libraries and running ldconfig afterwards solved the problem for me:

sudo rm /lib/x86_64-linux-gnu/libssl.so.1.1
sudo rm /lib/x86_64-linux-gnu/libcrypto.so.1.1
sudo ldconfig

Thanks to @waltinator and @Tilman for their comments.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.