LD_LIBRARY_PATH is not set by .bash_profile anymore after upgrade to Fedora 31

Hello everyone,

I upgraded to Fedora 31 on the weekend and noticed that my LD_LIBRARY_PATH is empty although I add several paths in my .bash_profile file. Other variables like PATH are set as before correctly. It seems to me that the login shell behaves somehow differently as in Fedora 30.

When I execute source .bash_profile then the LD_LIBRARY_PATH is loaded correctly without any errors.

Has anyone an idea how to fix that? Any help is highly appreciated!

I’ve added my .bash_profile file below.

Cheers,
Johannes

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi

# User specific environment and startup programs
LD_LIBRARY_PATH=/home/johannes/repositories/or-tools/lib:$LD_LIBRARY_PATH
1 Like

Hi Johannes.

What happens if you put export at the beginning of LD_LIBRARY_PATH=/home/johannes/repositories/or-tools/lib:$LD_LIBRARY_PATH? As in:

export LD_LIBRARY_PATH=/home/johannes/repositories/or-tools/lib:$LD_LIBRARY_PATH

Try logging out and back in as well.

4 Likes

Suggested reading:

2 Likes

Hi James,

adding export and logging out and in has no noticeable effect. LD_LIBRARY_PATH is still empty. As far as I understood it you only need to export variables in the .bashrc. I might be wrong though.

Humm…

Try running bash -l in a clean shell to simulate logging in. If that works, then it’s clear your graphical shell is not sourcing .bash_profile. Are you using Gnome or something else?

And yes, you would typically export vars defined in .bash_profile as well.

1 Like

It looks like as you would be on to something:

[johannes@galactica ~]$ echo $LD_LIBRARY_PATH

[johannes@galactica ~]$ bash -l
[johannes@galactica ~]$ echo $LD_LIBRARY_PATH
/home/johannes/repositories/or-tools/lib:

This means, as you say, that .bash_profile doesn’t get sourced. Nevertheless, it gets executed: If I add to the .bash_profile the following line echo $LD_LIBRARY_PATH > text.txt then a file containing the correct path is created during login.

I use Gnome and also tried both Wayland and Xorg. The system has been cleanly installed with Fedora 30 and I modified the system configuration as little as possible.

To be clear, are you now exporting LD_LIBRARY_PATH correctly in your .bash_profile? Can you paste your new version?

1 Like

I tried both variants with the same result:

# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi

# User specific environment and startup programs
LD_LIBRARY_PATH=/home/johannes/repositories/or-tools/lib:$LD_LIBRARY_PATH

export LD_LIBRARY_PATH

and to tell the full story:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi

# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
then
    PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH

Moreover, I want to point out that this is actually a minimal “not-working” example. I actually commented several other paths out. But all what I claimed above holds for this minimal example.

I did another experiment. I have created two virtual machines where I installed Fedora Workstation 30 and 31 using standard settings and updated them. Afterwards, I added to both .bash_profile files the following two lines

LD_LIBRARY_PATH=/home/johannes/Downloads:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

After restarting, echo $LD_LIBRARY_PATH returned on Fedora 30 the path while on Fedora 31 an empty line was printed.

I wonder if this is a bug or something like a security measure?

Well, strictly speaking, Gnome is not really supposed to source ~/.bash_profile, but rather it should source ~/.profile.

The ~/.profile file is shell-agnostic, and generally contains all your exported environment variable definitions, while the ~/.bash_profile file is bash-specific, and typically sources ~/.profile and ~/.bashrc (in that order).

For the sake of completeness, the ~/.bashrc file is sourced for non-login bash sessions (and indirectly via ~/.profile or ~/.bash_profile for login sessions). It contains bash-specific stuff, like aliasing and functions.

I’m not sure why Fedora decided to make Gnome source .bash_profile, or (in your case) revert this behavior. The odd thing is that I am also running Fedora 31, but it seems to work for me. The only thing left I can suggest is to do all your variable declarations in ~/.profile, such that Gnome will source it at graphical login, and also source it from ~/.bash_profile to handle SSH login sessions.

EDIT:
This may be of interest…
https://bugzilla.gnome.org/show_bug.cgi?id=736660

2 Likes

Reply Part 1/3. (I had to split my reply over 3 posts due to requirement that new users are limited to 2 links in a post.)

I confirm the same behavior.

While troubleshooting, I noticed

MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH

in the output of env, which led me to:

https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/VBFQMLGVPFVFV2RZDMFXNZ43HBU2CWCF/

I removed the environment-modules and scl-utils packages.

But the behavior persisted; the LD_LIBRARY_PATH environment variable was not present.

Investigating further, I noticed there is a difference between F30 and F31 in how ls diplays /usr/bin/gnome-shell:

On Fedora 31, you’ll see that it displays with a red background and yellow text.

The meaning of the red background and yellow text is discussed here in the context of /usr/bin/ping:

The discussion there explains that ls marks these executables in this way because they run with extra “capabilities.”

2 Likes

Reply Part 2/3. (I had to split my reply over 3 posts due to requirement that new users are limited to 2 links in a post.)

My simple understanding of “capabilities” is that they are a better alternative to setuid and setgid binaries.

For example, /usr/bin/ping used to be setuid in Fedora, and, in many linux distributions, it still is,

As a security measure, the loader removes many environment variables, including LD_LIBRARY_PATH, for setuid or setgid applications, as discussed here:

Bug 129682 - $LD_LIBRARY_PATH omitted from environment of setuid/setgid programs run by non-owner user

And, it seems, the same is done for executables with capabilities, as discussed here:

2 Likes

Reply Part 3/3. (I had to split my reply over 3 posts due to requirement that new users are limited to 2 links in a post.)

See also the “Secure-execution mode section” of the man page of ld.so:

http://man7.org/linux/man-pages/man8/ld.so.8.html#ENVIRONMENT

In summary, Fedora 31 changed /usr/bin/gnome-shell to run with capabilities, which causes it to run in a “secure-execution mode,” which, in turn, strips certain environment variables from the environment.

Then all the child processes of gnome-shell inherit its modified environment.

My understanding breaks down at this point, because I can’t explain how gnome-terminal is a child process of gnome-shell. I tried looking at the output of:

ps -aef --forest

but it doesn’t make that relationship evident. I suspect it has to do with ibus-daemon.

Note that, when you look at the output of ps -aef --forest, it is this line that starts bash as a login shell:

/usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "/usr/bin/gnome-session"

Note that if you open a guake terminal, you’ll get the behavior you expected; the LD_LIBRARY_PATH environment variable will be set as you specified in your ~/.bash_profile. This is consistent with the output of ps -aef --forest which shows that guake is started before gnome-shell.

Note also that GNOME 3.34 had a significant change to the relationship between systemd and gnome-session:

GNOME 3.34 is now managed using systemd

That might explain why there’s a difference between Fedora 30 and Fedora 31.

Robin

3 Likes

Exporting LD_LIBRARY_PATH on Fedora 31 in ~/.profile or ~/.bash_profile indeed does not work. Nevertheless it does work in ~/.bashrc. It is sad to see these fundamental things being change behind the scenes.