Ubuntu – How to Prevent Sudo from Changing $HOME and Disable This Behavior

environment-variablessudoUbuntu

On Ubuntu 12.04, when I sudo -s the $HOME variable is not changed, so if my regular user is regularuser, the situation goes like this:

$ cd
$ pwd
/home/regularuser
$ sudo -s
# cd
# pwd
/home/regularuser

I have abandoned Ubuntu a long time ago, so I cannot be sure, but I think this is the default behavior. So, my questions are:

Q1. How is this done? Where is the config?

Q2. How do I disable it?

Edit:
Thanks for the answers, which clarified things a bit, but I guess I must add a couple of questions, to get the answer I am looking for.

Q3. In Debian sudo -s, changes the $HOME variable to /root. From what I get from the answers and man sudo the shell ran with sudo -s is the one given in /etc/passwd, right?

Q4. However, on both Ubuntu and Debian the shell given in /etc/passwd for root is /bin/bash. In either system also, I cannot find where the difference in .profile or .bashrc files is, as far as $HOME is concerned, so that the behavior of sudo -s differs. Any help on this?

Best Answer

Sudo has many compile-time configuration options. You can list the settings in your version with sudo -V. One of the differences between the configuration in Debian wheezy and in Ubuntu 12.04 is that the HOME environment variable is preserved in Ubuntu but not in Debian; both distributions erase all environment variables except for a few that are explicitly marked as safe to preserve. Thus sudo -s preserves HOME on Ubuntu, while on Debian HOME is erased and sudo then sets it to the home directory of the target user.

You can override this behavior in the sudoers file. Run visudo to edit the sudoers file. There are several relevant options:

env_keep determines which environment variables are preserved. Use Defaults env_keep += "HOME" to retain the caller's HOME environment variable or Defaults env_keep -= "HOME" to erase it (and replace it by the home directory of the target user).
env_reset determines whether environment variables are reset at all. Resetting environment variables is often necessary for rules that allow running a specific command, but does not have a direct security benefit for rules that allow running arbitrary commands anyway.
always_set_home, if set, causes HOME to be overridden even if it was preserved due to env_reset being disabled or HOME being in the env_keep list. This option has no effect if HOME isn't preserved anyway.
set_home is like always_set_home, but only applies to sudo -s, not when calling sudo with an explicit command.

These options can be set for a given source user, a given target user or a given command; see the sudoers manual for details.

You can always choose to override HOME for a given call to sudo by passing the option -H.

The shell will never override the value of HOME. (It would set HOME if it was unset, but sudo always sets HOME one way or another.)

If you run sudo -i, sudo simulates an initial login. This includes setting HOME to the home directory of the target user and invoking a login shell.

Related Solutions

Bash – How to prevent the caller’s shell from being used in sudo

Then answer is that sudo has a bug. First, the workaround: I put this in my /etc/sudoers.d/zabbix file:

zabbix    ALL=(root) NOPASSWD:       /bin/env SHELL=/bin/sh /usr/local/bin/zabbix_raid_discovery

and now subcommands called from zabbix_raid_discovery work.

A patch to fix this will be in sudo 1.8.15. From the maintainer, Todd Miller:

This is just a case of "it's always been like that".  There's not
really a good reason for it.  The diff below should make the behavior
match the documentation.

 - todd

diff -r adb927ad5e86 plugins/sudoers/env.c
--- a/plugins/sudoers/env.c     Tue Oct 06 09:33:27 2015 -0600
+++ b/plugins/sudoers/env.c     Tue Oct 06 10:04:03 2015 -0600
@@ -939,8 +939,6 @@
            CHECK_SETENV2("USERNAME", runas_pw->pw_name,
                ISSET(didvar, DID_USERNAME), true);
        } else {
-           if (!ISSET(didvar, DID_SHELL))
-               CHECK_SETENV2("SHELL", sudo_user.pw->pw_shell, false, true);
            /* We will set LOGNAME later in the def_set_logname case. */
            if (!def_set_logname) {
                if (!ISSET(didvar, DID_LOGNAME))
@@ -984,6 +982,8 @@
            if (!env_should_delete(*ep)) {
                if (strncmp(*ep, "SUDO_PS1=", 9) == 0)
                    ps1 = *ep + 5;
+               else if (strncmp(*ep, "SHELL=", 6) == 0)
+                   SET(didvar, DID_SHELL);
                else if (strncmp(*ep, "PATH=", 5) == 0)
                    SET(didvar, DID_PATH);
                else if (strncmp(*ep, "TERM=", 5) == 0)
@@ -1039,7 +1039,9 @@
     if (reset_home)
        CHECK_SETENV2("HOME", runas_pw->pw_dir, true, true);

-    /* Provide default values for $TERM and $PATH if they are not set. */
+    /* Provide default values for $SHELL, $TERM and $PATH if not set. */
+    if (!ISSET(didvar, DID_SHELL))
+       CHECK_SETENV2("SHELL", runas_pw->pw_shell, false, false);
     if (!ISSET(didvar, DID_TERM))
        CHECK_PUTENV("TERM=unknown", false, false);
     if (!ISSET(didvar, DID_PATH))

Bash – sudo not executing bashrc as expected

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

Related Solutions

Bash – How to prevent the caller’s shell from being used in sudo

Bash – sudo not executing bashrc as expected

Related Question