Detailed explanation of the initialization mechanism in bash

Bash Initialization Files

Interactive login shell

We can get a login shell in the following cases:

• The top-level shell you get when you log in to the system, whether through a local terminal or through ssh over the network. The login shell obtained in this case is an interactive shell.
• Invoke bash with the --login option in a terminal to get an interactive login shell.
• Invoking bash with the --login option in a script (for example: #!/bin/bash --login) produces a non-interactive login shell.
• When you use su - to switch to a specified user, you get the login shell of this user. Without -, you get a non-login shell.

When the login shell starts, it first reads the system global configuration /etc/profile, then searches for the three configuration files ~/.bash_profile, ~/.bash_login, and ~/.profile in turn, and reads the first readable file found.

When the login shell exits, it reads and executes the commands in ~/.bash_logout. If the configuration file exists but is unreadable, an error message is displayed; if the file does not exist, bash automatically searches for the next file.

By default, global environment variables such as PATH, USER, MAIL, HOSTNAME, HISTSIZE, etc. are defined in the /etc/profile file. The /etc/bash.bashrc file (containing system-level shell functions and aliases) and all *.sh files in the /etc/profile.d path that are used to initialize specific programs are also automatically imported.

Interactive non-login shell

A non-login shell means that you do not have to authenticate to the system when you start it. The terminal opened by the user in the GUI is a non-login shell by default, which can be determined by the logout command:

# Open a terminal on the Ubuntu GUI desktop > logout
bash: logout: not login shell: use `exit'
> bash --login
> logout # Log out normally and nothing will be output

When a non-login shell is initialized, it only reads the ~/.bashrc resource file, and the ~/.bashrc file is automatically loaded by ~/.bash_profile or ~/.profile. Therefore, in order to ensure that the login shell and the interactive non-login shell get the same configuration, the environment variables are generally defined in the ~/.bashrc file.

> echo "export sflag=\"login shell will see this message\"" >> ~/.profile  
> bash 
> echo $sflag 
          # If the variable is not found, a blank line will be printed> exit 
> bash --login 
> echo $sflag 
The login shell will see this message 
> logout

Non-interactive shell

When the script is executed through the bash command, the shell is started in a non-interactively way, which ensures that the script will not be interfered with by the user during execution. When a non-interactive script is started, only the file pointed to by the BASH_ENV variable is loaded. But please note that since the PATH variable is not loaded by non-interactive shells by default, the value of the variable BASH_ENV should be an absolute path.

You can view the current shell mode through the special variable -:

> echo $-
himBHs # with 'i' is interactive shell

Another simple way is to check if the prompt environment variable PS1 exists in the current shell.

if [ -z "$PS1" ]; then echo "non-interactive";else echo "interactive";fi

Special circumstances

Compatibility Mode

If you use the sh command to call bash, bash will be initialized in the same way as sh to ensure compatibility. When started as a login shell, bash reads the /etc/profile and ~/.profile configuration files in that order. When started as a non-login shell, bash reads only the file pointed to by the ENV environment variable.

POSIX mode

When starting bash via:

1. set -o posix or export POSIXLY_CORRECT=1
2. bash --posix

Bash will try to initialize according to the POSIX standard and only read the file pointed to by the environment variable ENV.

Remote startup script

When using rshd to remotely start the script, only the ~/.bashrc file will be loaded. However, please note that you should try not to use remote commands such as rlogin, telnet, rsh, rcp, etc., because these commands will transmit unencrypted plain text information. If you need remote access, try to use SSH.

UID and EUID do not match

When a process is created, the information required for the process to run will be recorded in task_struct. The UID (real user ID) is used to record the ID of the user who created the process, and the EUID (effective user ID) is used to determine the access level of the current process to the file. Generally, UID = EUID. If the set-user-ID: SUID bit of an executable file is valid (for example: -rwsr-xr-x, where the user's x is replaced by s), it means that when the file is executed, the process has the permissions of the file owner rather than the executor (the value of EUID is the ID of the file owner).

If we set the set-user-id flag for the bash executable file, then since its default owner is root, when other non-root users run bash, the UID of the process will not be equal to the EUID. In this case, in order to ensure security, bash will not load any files during the initialization phase.

Restricted shell

When started via rbash or bash --restricted or bash -r, a shell with restricted functionality is generated, as follows:

• The cd command cannot be used and the command cannot contain /
• The SHELL, PATH, ENV, and BASH_ENV environment variables cannot be changed
• The source command parameter cannot contain files with /
• The parameters of the command used to alias the path cannot contain /
• Functions in the file are not imported during initialization and SHELLOPTS is ignored.
• Redirection cannot be used
• Cannot use exec command
• Cannot use enable -f/-d to add or delete commands
• You cannot use command -p to specify the path required to run the command.
• Cannot automatically turn off restricted mode

In theory, this feature allows users to execute specified files in a specified folder to complete limited functions. However, if the environment variables are not set properly, users can easily remove the restrictions:

> rbash
> cd /etc
rbash: cd: restricted
> bash
> cd /etc # This can be executed successfully because we are in bash environment and there are no restrictions.

An effective approach is to limit the commands that can be executed by the newly created user. For example, we can create a ruser that can only execute ftp commands:

> useradd -s /bin/rbash ruser # Set the shell provided when the user logs in
> chown -R root:ruser /home/ruser/.bashrc /home/ruser/.bash_profile
# Set root as the owner and ruser group as the group owner (the new ruser is entered as ruser group by default)
>chmod 640 /home/ruser/.bashrc /home/ruser/.bash_profile
# root can read and write, users in the ruser group can only read, other users can do nothing> mkdir /home/ruser/bin # store user executable files or links> echo "export PATH=/home/ruser/bin" >> /home/ruser/.bash_profile
> ln -s /user/bin/ftp /home/ruser/bin/ftp

This is the end of this article about the detailed explanation of the initialization mechanism in bash. For more relevant bash initialization content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!