Bug 1478651

Summary:	For sudo --login [command], .bash_profile is not read by shell
Product:	[Fedora] Fedora	Reporter:	Don Swaner <Gecko8211>
Component:	sudo	Assignee:	Marek Tamaskovic <mtamasko>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	25	CC:	dkopecek, jvymazal, kzak, mattdm, mtamasko, rsroka, tosykora
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-12 21:10:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Don Swaner 2017-08-05 16:18:23 UTC

Description of problem:
When "sudo --login" (without a command specified) is run, .bash_profile	is read by the shell, in agreement with what the sudo man page states.  However, when "sudo --login [command]" (with a command specified) is run, .bash_profile is not read by the shell, contrary to what the sudo man page states.

Version-Release number of selected component (if applicable):
sudo-1.8.20p2-1.fc25.x86_64

How reproducible:
Always

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.

Actual results:
When running "sudo --login ll", an error message results.

Expected results:
When running "sudo -i ll", the .bash_profile is read by the shell, and the command alias properly executes.


Additional info:
If this sudo behavior is considered to be correct, then the sudo man page needs to be clarified.

Comment 1 Marek Tamaskovic 2017-09-25 07:11:41 UTC

In doumentation is specified, when using --login, that only .profile and .login will be read by shell. Everything else will be erased including variables.

What do you mean by clarification in man pages?

Comment 2 Don Swaner 2017-09-25 14:14:19 UTC

The .login file is for the tcsh shell, and .profile is maybe used by some installations for the bash shell. In Fedora, this file corresponds to .bash_profile for the bash shell. I'm not suggesting that the references to .login and .profile need to be changed (even though they are not used in Fedora).

What I mean by clarification is:
ASSUMING THAT THE CURRENT "sudo --login" BEHAVIOR IS DEEMED TO BE CORRECT, then the man page could be changed as follows:

The sudo man page currently reads:
...
-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. If no command is specified, an interactive shell is executed. ...

This sudo man page section, could be changed to something like:
...
-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 NO COMMAND IS SPECIFIED. If a command is specified, it is passed to the shell for execution via the shell's -c option, HOWEVER IN THIS CASE, .PROFILE or .LOGIN ARE NOT READ. If no command is specified, an interactive shell is executed. ...

Or, perhaps better would be:
...
-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 3 Marek Tamaskovic 2017-10-12 09:31:49 UTC

Try consult this changes with upstream. There is the right place to suggest improvements in documentation.
https://bugzilla.sudo.ws/index.cgi

Comment 4 Don Swaner 2017-10-12 12:00:50 UTC

Added comments to: https://bugzilla.sudo.ws/show_bug.cgi?id=806

Comment 5 Don Swaner 2017-10-12 16:00:21 UTC

Resolution from bugzilla.sudo.ws:

Comment # 8 on bug 806 from Todd C Miller
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 6 Don Swaner 2017-10-12 20:53:04 UTC

Sorry, but the proposed solution does not work.  Original symptoms are unchanged with "shopt -s expand_aliases" (in both .bash_profile and .bashrc). I will comment at bugzilla.sudo.ws.

Comment 7 Don Swaner 2017-10-12 21:10:07 UTC

The proposed solution does work, if the "shopt -s expand_aliases" is added to root's .bash_profile, not the user's profile.