Bug 1478651 - For sudo --login [command], .bash_profile is not read by shell
For sudo --login [command], .bash_profile is not read by shell
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
25
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Marek Tamaskovic
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-05 12:18 EDT by Don Swaner
Modified: 2017-10-12 17:10 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-12 17:10:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Don Swaner 2017-08-05 12:18:23 EDT
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 03:11:41 EDT
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 10:14:19 EDT
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 05:31:49 EDT
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 08:00:50 EDT
Added comments to: https://bugzilla.sudo.ws/show_bug.cgi?id=806
Comment 5 Don Swaner 2017-10-12 12:00:21 EDT
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 16:53:04 EDT
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 17:10:07 EDT
The proposed solution does work, if the "shopt -s expand_aliases" is added to root's .bash_profile, not the user's profile.

Note You need to log in before you can comment on or make changes to this bug.