How to customize Linux user environments

System security is a major concern. As a sysadmin, as I've stated before, it's your primary concern. Adding users to a system decreases security. Your job is to create a usable but secure environment for your users. You have corporate assets to protect, systems to maintain, and users to satisfy. There's often a conflict among those three aspects of system administration, as you well know. One way to satisfy all three is to customize your user's environments by implementing and enforcing a corporate standard. Striking a balance between user productivity and system security isn't easy. I can't write specifications for your particular situation, but I can show you where to make the necessary changes so that you can do so.

This article covers customizing your user's environments using files found in the /etc/skel and /etc/profile.d directories. With a fresh system install, you'll find three files under /etc/skel: .bash_logout, .bash_profile, and .bashrc. When you create a new user account on a system, these three files are copied to the user's home directory and are owned by the user. In case you don't know, so-called dot files (those named with a preceding dot (.) are hidden from standard file lists. To see them, you must use the -a switch with the ls command.

-rw-r--r--.  1 root root   18 Mar 31 21:17 .bash_logout
-rw-r--r--.  1 root root  193 Mar 31 21:17 .bash_profile
-rw-r--r--.  1 root root  231 Mar 31 21:17 .bashrc

As you can see, these files are owned by root and can only be edited or changed by the root user.

.bash_profile

The .bash_profile file is the most important of the three files listed. It's most important because it is the only "required" file in the list. It executes every time the user logs into a system, it launches the .bashrc file, and defines and exports the PATH variable. Its default settings are simple.

# .bash_profile

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

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH

The .bash_profile can also be used to define a custom shell prompt, define one's editor of choice, or anything else that you want to place into the file for the user.

[ You might also like: Linux environment variable tips and tricks ]

.bashrc

The contents of the .bashrc file, by default, only call the /etc/bashrc file. The /etc/bashrc file consists of settings that can be configured for all users.

# .bashrc

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

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

# User specific aliases and functions

You could call other files configured for certain user groups as well. For example, if a user is a member of the finance group, you could call a file to set up a particular set of variables for all users in the finance group.

/etc/bashrc and /etc/profile

The listing for /etc/bashrc is far too long for this venue, but you can look at it and see what it does. The /etc/bashrc file refers to the /etc/profile file for more environment variables and settings. Both files come with the following warning.

# It's NOT a good idea to change this file unless you know what you
# are doing. It's much better to create a custom.sh shell script in
# /etc/profile.d/ to make custom changes to your environment, as this
# will prevent the need for merging in future updates.

So, you see, customizing a user environment is not as simple as you thought.

/etc/profile.d

If you list the files in /etc/profile.d, you'll see the following:

-rw-r--r--.  1 root root  771 Mar 31 21:50 256term.csh
-rw-r--r--.  1 root root  841 Mar 31 21:50 256term.sh
-rw-r--r--.  1 root root  196 Mar 24  2017 colorgrep.csh
-rw-r--r--.  1 root root  201 Mar 24  2017 colorgrep.sh
-rw-r--r--.  1 root root 1741 Aug  6  2019 colorls.csh
-rw-r--r--.  1 root root 1606 Aug  6  2019 colorls.sh
-rw-r--r--.  1 root root   80 Mar 31 23:29 csh.local
-rw-r--r--.  1 root root 1706 Mar 31 21:50 lang.csh
-rw-r--r--.  1 root root 2703 Mar 31 21:50 lang.sh
-rw-r--r--.  1 root root  123 Jul 30  2015 less.csh
-rw-r--r--.  1 root root  121 Jul 30  2015 less.sh
-rw-r--r--.  1 root root   81 Mar 31 23:29 sh.local
-rw-r--r--.  1 root root  164 Jan 27  2014 which2.csh
-rw-r--r--.  1 root root  169 Jan 27  2014 which2.sh

You can see that many of the files are for use in the C shell. The most important file for this article's focus is sh.local. The contents of sh.local is listed below.

#Add any required envvar overrides to this file, it is sourced from /etc/profile

As you can see from the message, if you want to override any currently configured envvar (Environment variables) entries with a corporate standard, make entries in this file to do that.

Caveats

As users learn more about their environments and Google things, they'll customize their own—often to their detriment. You have to strike a balance between being a laissez-faire sysadmin and a heavy-handed dictator sysadmin. You want users to be productive but have some limited control over their own environments. My suggestion to make both sides happy is to set all corporate standard user environment parameters in /etc/bashrc and in /etc/profile.d/sh.local that you don't want to be edited or changed.

Realize that the /home/user/.bash_profile, .bashrc, and .bash_logout are user-editable files. The only way around this is to change permission on those files with a root user script after you create the accounts. In other words, run a script after you create a user account to change the permissions on the /home/user/.bash* files to root: rw-r--r--. The user won't be able to alter the files.

If you want to lock down the environment by changing the .bash* files to root ownership, you could create a new file in /etc/skel such as a .user file that the user can edit and include it in the .bash_profile file.

[ Want to learn more about security? Check out the IT security and compliance checklist. ] 

Wrap up

Customizing a user's environment can enhance system security and standardize what users see and how they interact with a system. Granting shell access to a production system has its own implications, but you must provide resources for your users to maximize their productivity and maximize system security. If you find that perfect balance, please write it up into an article for Enable Sysadmin. In my own experience, every user feels that they are the exception to the corporate standard and, pretty soon, you have a bunch of exceptions and no corporate standard at all.