Bug 806

Summary:	-i / --login does not initialize the environment as documented
Product:	Sudo	Reporter:	Carson Gaspar <gaspar>
Component:	Sudoers	Assignee:	Todd C. Miller <Todd.Miller>
Status:	ASSIGNED ---
Severity:	normal	CC:	dswaner
Priority:	low
Version:	1.8.21
Hardware:	PC
OS:	Linux

Description Carson Gaspar 2017-09-26 12:22:27 MDT

From sudoers(5):

"As a special case, if sudo's -i option (initial login) is specified, sudoers will initialize the environment regardless of the value of     env_reset.  The DISPLAY, PATH and TERM variables remain unchanged; HOME, MAIL, SHELL, USER, and LOGNAME are set based on the target     user.  On AIX (and Linux systems without PAM), the contents of /etc/environment are also included.  All other environment variables are removed."

Not true, it seems that env_keep variables are also kept:

$ PS1=SHOULDGOAWAY sudo -i -u pyvenv env | grep '^PS1='
PS1=SHOULDGOAWAY

Comment 1 Todd C. Miller 2017-09-26 13:10:13 MDT

This is a documentation error.  In the old days there was a bigger difference between "sudo -i" and "sudo -s".  Now that env_reset is the default, there is not so much difference.

https://www.sudo.ws/repos/sudo/rev/5f5568c6fdd9

Comment 2 Carson Gaspar 2017-09-26 13:33:53 MDT

Wanting different behaviour for -i and -s is sane. I have users doing "sudo su - someuser" because sudo -i preserves PS1, DISPLAY, etc.

I don't see a way to have different values for env_keep if -i is passed as an argument, so it looks like sudo has regressed from its former correct behaviour.

Comment 3 Todd C. Miller 2017-09-26 13:36:39 MDT

I don't believe this is a change in behavior, can you point to a version of sudo where "sudo -i" did not honor env_keep?  I checked as far back as sudo 1.6.9p23 and the behavior appears to be the same.

Comment 4 Carson Gaspar 2017-09-26 13:43:51 MDT

Either I'm confused, or I'm remembering truly ancient versions. So I guess I'll just have to recommend the "sudo su" hack to get a properly clean environment for login shells. That makes me sad.

Comment 5 Don Swaner 2017-10-12 05:56:11 MDT

Another perspective on this issue:

when "sudo --login [command]" (with a command specified) is run, .profile is not read (and command aliases are not available), contrary to what the sudo man page states.

Assuming that the current sudo behavior is deemed correct, the following is a suggested change to the man page:

...
 -i, --login
Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell.  If a command is specified, it is passed to the shell for execution via the shell's -c option, AND THE --login OPTION IS IGNORED, AND .profile OR .login ARE NOT READ.  If no command is specified, an interactive shell is executed. ...

Comment 6 Todd C. Miller 2017-10-12 08:32:59 MDT

Don, the behavior of "sudo -i command" and the reading of .profile is somewhat shell-dependent.  Historically, the Unix shell would read .profile even when the -c option was given when the shell's name (argv[0]) started with a '-'.

However, not all modern shells do this.  A notable exception is bash, which only reads .profile if the --login option is also specified.  Sudo includes a workaround for this and passes --login along with -c.

What shell are you using that is not loading .profile when "sudo -i" is used with a command?

Comment 7 Don Swaner 2017-10-12 09:29:07 MDT

(In reply to Todd C Miller from comment #6)
> What shell are you using that is not loading .profile when "sudo -i"
> is used with a command?

bash shell, bash-4.4.12-7.fc26.x86_64, Fedora 26 workstation (gnome desktop).  The bash profile is named ".bash_profile", which pulls in /etc/bashrc, which defines some command aliases.  The problem showed up here:

Steps to Reproduce:
1. Run "sudo --login".  A root login shell with '#' prompt is presented. Enter an alias for a command, such as "ll", and the command output is displayed. Exit the root shell.
2. Run "sudo --login ll", and a	error message is displayed: "bash: ll: command not found" - the same error displayed when "sudo ll" is run.

Comment 8 Todd C. Miller 2017-10-12 09:45:04 MDT

From the bash manual:

Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).

When you run a command via "sudo -i" the shell is not in interactive mode so aliases are not applied.  If you use a shell function instead of an alias this is not an issue.  Adding "shopt -s expand_aliases" to the top of 
.bash_profile should give you the behavior you want.

Comment 9 Don Swaner 2017-10-12 09:53:28 MDT

(In reply to Todd C Miller from comment #8)
> From the bash manual: ...

Thank you. I will pass that back to the Red Hat folks that sent me here, and also to the Fedora Forum where the issue first showed up.