sudo can be configured to set $HOME to match the new user when switching users, or not to. In your case, it appears it is set to not switch $HOME. That can be useful when you want to switch to user accounts that are dedicated to specific service applications, but still want to keep using your personal shell configuration and other settings.
And ~/.bashrc is actually just a shorthand for $HOME/.bashrc.
So when you do sudo -u newuser bash, sudo switches the username to newuser but $HOME is still set to /home/myuser.
When bash attempts to execute ~/.bashrc, it has a slight problem: as newuser, it might have no access to read /home/myuser/.bashrc unless you have specifically granted that access. If you haven't, that is probably why .bashrc is getting skipped. Because $HOME is still set to /home/myuser, there will be no attempt to execute /home/newuser/.bashrc.
If you want sudo to set HOME=/home/newuser, you can:
- use the
-H option with the sudo command: sudo -Hu newuser bash
- or add
Defaults>newuser always_set_home to your sudoers file to automatically set the home directory when switching to newuser only
- or add
Defaults:myuser always_set_home to sudoers file to automatically set the home directory to match the new identity when myuser is running any sudo commands
- or add
Defaults always_set_home to sudoers file to force this behavior for all sudo commands on the system. (Some Linux distributions have this enabled by default.)
If you don't especially want to switch the home directory when switching users, then you'll need to make sure the new user can read your personal shell startup files instead.
The minimal permissions you'd need to allow for sudo -u newuser bash to run /home/myuser/.bashrc are:
- a search permission to
/home/myuser
- a read permission to
/home/myuser/.bashrc
If there is no convenient user group that would be common to both myuser and newuser, and ACLs are not available (i.e. traditional Unix-style permissions only), this would be the traditional way to do it:
chmod 711 /home/myuser # i.e. directory permissions drwx--x--x
chmod 644 /home/myuser/.bashrc # i.e. file permissions -rw-r--r--
If ACLs are available for the filesystem containing your home directory, you could do this instead to grant the minimal necessary access:
setfacl -m u:newuser:x /home/myuser
setfacl -m u:newuser:r /home/myuser/.bashrc
If the permissions of the home directory were initially drwx------, after this command the permissions to /home/myuser would look like drwx--x---+. To check the complete ACL, use getfacl:
$ getfacl /home/myuser
getfacl: Removing leading '/' from absolute path names
# file: home/myuser
# owner: myuser
# group: myuser
user::rwx
user:newuser:--x
group::---
mask::--x
other::---
Best Answer
The error comes from trying to execute the
~/.profilefile withsh, which does not understandsource(shuses.(dot) instead, which also works inbashand all other POSIX shells).Furthermore, executing
~/.profilewill not set the environment variables that this file sets in the shell that executes it. This is because it runs in its own subshell.A child shell (which is what you get when you execute
~/.profilerather than sourcing it) will never affect the environment of the parent shell (the shell that you execute the script from). You can therefore not set variables in~/.profileand expect them to then be set in your script unless yousourcethe file.Running
sudo source ~/.profilewill not help here assudowill be a child process of the current shell.Related, extra information:
To set up the environment for a script that is not run from an interactive shell (where
~/.profileand~/.bashrcare already sourced), set theBASH_ENVvariable to the appropriate file upon invoking the script. This will makebashsource the$BASH_ENVfile before handing control over to your script.For example:
This is only necessary if invoking the script from a non-interactive shell session, such as a cron job, and if you need to access environment variables set up in
~/.profileor any file that~/.profilesources.From an interactive shell session, the
BASH_ENVvariable does not have to be set in this way, and the script does not need to source~/.bashrcnor~/.profilesince these have already been sourced.