Unexpected /etc/profile.d behavior

Rocky Linux General
1

I am seeing several environment variables bound in a .sh file in /etc/profile.d that are unbound for a user login when the .sh file in /etc/profile.d is a symbolic link to a file contained in a subdirectory of /root. When I replace the symbolic link with an actual file, all is fine.

I’m running RL v8.7 on an AWS EC2 instance.

An example may clarify. My company is named “Zeetix”. The /root directory contains a subdirectory named /root/zeetix_environment. This subdirectory contains zeetix.sh, with the following trivial content:

export FOOBAR=00

In /etc/profile.d, I create a symbolic link as follows:

ln -s /root/zeetix_environment/zeetix.sh zeetix.sh

An ls -l command confirms the valid link:

# ls -l /etc/profile.d/zeetix.sh
lrwxrwxrwx 1 root root 34 Jul  3 00:28 /etc/profile.d/zeetix.sh -> /root/zeetix_environment/zeetix.sh

When I log in as the root user, I see the expected result:

# printenv FOOBAR
00

I reboot the system and login as a user (‘tms’). I expect FOOBAR to be defined, and it is not:

$ printenv FOOBAR
$

I replace the symbolic link in /etc/profile.d with the actual file zeetix.sh and restart. I then login as the ‘tms’ user again.

The same FOOBAR environment variable is now defined:

$ printenv FOOBAR
00
$

What is going on?

I notice that the following ls command shows a broken link while /etc/profile.d/zeetix.sh is a link and I’m logged in as a user.

$ ls -l /etc/profile.d/zeetix.sh

Is this some kind of permissions issue?

I want to use a symbolic link because /root/zeetix_environment is a git repo. I maintain multiple systems and I want the bindings in zeetix.sh to be available on each system. By using a symbolic link, I can more readily deploy changes to the environment (using a git pull in /root/zeetix_environment).

I apologize if this is something I should already know, and I appreciate your attention.

I invite the guidance of this community as to what is going on.

2

You cannot expect a user to be able to traverse /root. This explains the behavior you’re seeing. As an aside, just because a symbolic link shows 777, it does not imply the actual permissions of the file nor the permissions of the directory/directories it sits in.

The file needs to be outside of /root and world readable, whether or not you put it in /etc/profile.d or you put it somewhere like /opt/zeetix_environment and symlink it there.

1 Like
3

I appreciate your immediate and helpful response. The giveaway for me is that – not surprisingly – the permissions on /root disallow read access for the world.

I retargeted the link in /etc/profile.d to a directory in tms and all is well.

Thanks SO much for your attention and polite response. :slight_smile: