By default, this is the user's password, not the root password itself. The real and effective uid and gid of the issuing user are then set to match those of the target user account as specified in the passwd file.īy default, sudo requires that users authenticate themselves with a password. The /etc/profile has: pathmunge /usr/local/sbinĪnd /root/.bashrc has: PATH="$HOME/.Sudo allows a permitted user to execute a command as another user, according to specifications in the /etc/sudoers file. The /etc/sudoers has also: Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin If the PATH and TERM variables are not preserved from the user’s environment, they will be set to default values. The PATH is not preserved by sudoers and man 5 sudoers writes: root/.local/bin:/root/bin:/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin The Command environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use. Note that most shells behave differently when a command is specified as compared to an interactive session consult the shell’s manual for details. The command is run with an environment similar to the one a user would receive at log in. sudo attempts to change to that user’s home directory before running the shell. If no command is specified, an interactive shell is executed. If a command is specified, it is passed to the shell for execution via the shell’s -c option. This means that login-specific resource files such as. Run the shell specified by the target user’s password database entry as a login shell. sets argv of the shell to ‘-’ in order to make the shell a login shell.changes to the target user’s home directory.initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH. clears all the environment variables except TERM and variables specified by -whitelist-environment.Start the shell as a login shell with an environment similar to a real login: Is this a bug, or am I just missing something? This isn’t what I’d expected–in my past experience (and according to the sudo man page), sudo -i gives root’s login environment, but that clearly isn’t happening here. OTOH, /sbin is in root’s path if I do sudo -i, but not if I do sudo su. usr/local/bin is in the unprivileged user’s path, and it’s also in root’s path if I do sudo su -–but it isn’t there if I do sudo -i. root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin Last login: Wed Mar 8 06:19: on ~]# echo $PATH Then, to install the software I wanted, I used sudo -i to become root and ran the installer–which failed, due to a $PATH problem.įurther investigation revealed that $PATH is different depending on whether I become root using sudo -i or sudo su -: ~]$ echo ~]$ sudo -i I’d set up a non-root user as an administrator during the installation. I’d installed Rocky 9.1 with the minimal installation, adding only the hypervisor guest packages as it was running as a VM under Proxmox. I ran into a problem over at NS8 installation on Rocky Linux fails - Bug - NethServer Community, and in troubleshooting it I encountered something unexpected.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |