# [solved] Help! I somehow screwed up $PATH for root [solved]

## Odysseus

I don't know if this is the correct forum, so mods please feel free to move if required.

I need some help pretty badly. I have been trying to build Cyanogenmod and Evervolv (Android aftermarket ROMs) for my handset. I was having difficulty getting sudo to recognize the extra entries I had made to my $PATH statement to get the android-sdk working and git to initialize git in the new partition I created for Android development.

My user needed escalated privileges since I had created the required directories in /opt due to lack of space in my user's home directory. I had also placed some needed binaries in /usr/local/bin, example repo command. The problem was sudo (my preferred method of doing most work requiring escalated privileges) was only recognizing a small stripped subset of my user's $PATH. I tried a few things I read on other forums and succeeded in getting sudo to recognize the additional entries to $PATH, but I somehow screwed up something and now su no longer recognizing the entire $PATH and is behaving like sudo had been doing previously. 

I've been trying for the last several hours to backtrack and see what I did to mess things up, but I can't for the life of me figure it out.

Here is what I'm talking about:

```
As my regular user:

~ $ echo "$PATH"

/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/usr/games/bin

Evoking sudo:

~ $ sudo echo "$PATH"

Password: 

/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/usr/games/bin

As su:

# echo "$PATH"

/sbin:/bin:/usr/sbin:/usr/bin

```

As you can see su is now stripped of all but the minimum entries to $PATH and is behaving as sudo had been previously. I'm at a loss on how to proceed. I've been using this Gentoo installation since 2004. It's survived several hardware upgrades and a conversion from x86 to ~amd64 (and the corresponding change of CHOST to x86_64-pc-linux-gnu).

I'm rather proud that a self-taught truck driver like myself, with no formal computer training, has been able to maintain this for so long without ever needing to start over from scratch. So I would prefer to figure out a way to correct my error and salvage the situation than having to start all over again. Any help would extremely appreciated. TIALast edited by Odysseus on Tue Apr 29, 2014 9:30 pm; edited 4 times in total

----------

## Jaglover

```
su - 

echo "$PATH" 
```

Does it look different?

----------

## Odysseus

 *Jaglover wrote:*   

> 
> 
> ```
> su - 
> 
> ...

 

Yes it does. When I evoke su as you suggest it looks like this:

```
 ~ # echo "$PATH"

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools
```

This is how the $PATH used to look for su.

The question is, what do I need to do to revert su to its prior state so it behaves like this without adding '-'?

----------

## Odysseus

bumb

It's been a week, I'm still having this issue. Anyone have any ideas for a solution? TIA

----------

## John R. Graham

Security on su has been tightened up for a while; providing a minimal path is now the default, whereas the --login (short form -l or a lone - as the last argument) option is now required to get a full path. Alas, you're going to have to live with the extra dash.  :Wink: 

- John

----------

## khayyam

John, Odysseus, et al ...

hasn't it *always* been this way, I've always considered '--login', '-l', or '-', to be necessary for a login shell, I don't think I can every remember a time when this wasn't the case (though I almost always use '-' as I almost certainly want that the environment is correct for the UID). Take this post from the zsh-users mailing list circa 1997, a similar request, and the same behavior with 'su' sans '-l' ... and looking at the Changelog for sys-apps/shadow besides the sanitize_env() from 2010 I see nothing suggesting a recent change (though, that patch was removed in January, so prehaps upstream gave it some love recently).

 *Osysseus wrote:*   

> The problem was sudo (my preferred method of doing most work requiring escalated privileges) was only recognizing a small stripped subset of my user's $PATH.

 

It won't help if you're using bash, but the following method can be used with zsh ...

~/.zprofile

```
if [[ $EUID != 0 ]] && (($+commands[sudo])) ; then

    typeset -xT SUDO_PATH sudo_path

    typeset -U sudo_path 

    sudo_path=({,/usr/local,/usr}/sbin(N-/))

fi
```

~/.zshrc

```
zstyle ':completion:*:sudo:*' environ PATH="$SUDO_PATH:$PATH"
```

... now the commands are in path when using sudo .... and have completion.

```
% rc<tab>

---- external command

---- alias

rc-config rc-status rcp^C

% sudo rc<tab>

---- external command

rc rc-config rc-service rc-status rc-update
```

best ... khay

----------

## John R. Graham

In short, no. Some small number of years ago on Gentoo (perhaps 2-3), a lone "su" would give you a full path. I'm fairly monotheistic where Linux distributions are concerned, so I have no idea how other distributions behaved. But, since Gentoo follows upstream very closely, I would suspect this was an upstream change.

- John

----------

## cwr

AFAIK "su" maintains the user's path, whereas "su -" moves to root's path,

essentially a root login.  It's been like that for at least five years.  The default

paths are set in /etc/profile, and my (edited) version is:

```

#

# Yes, I know a leading ".:" is a bad idea.

#

if [ "$EUID" = "0" ] || [ "$USER" = "root" ] ; then

   PATH="/usr/local/sbin:/usr/local/bin:/opt/bin:/usr/sbin:/usr/bin:/sbin:/

bin":${PATH}

else

   PATH=".:/usr/local/bin:/opt/bin:/usr/bin:/bin:${PATH}"

fi

export PATH

```

See also "man su".

Will

----------

## John R. Graham

Except that su presented by itself doesn't source /etc/profile. It doesn't set up a "user's path" but an intentionally minimal path.

- John

----------

## cwr

 *John R. Graham wrote:*   

> Except that su presented by itself doesn't source /etc/profile. It doesn't set up a "user's path" but an intentionally minimal path.
> 
> - John

 

Hmm,  no, nor it does,  I must have remembered that from an unconfigured system which had a minimal root path.

Thanks - Will

----------

## Odysseus

Thanks for all of your input. Unfortunately, it seems that although the behavior I've been experiencing isn't normal no one had any ideas as to a solution. So I got desperate and did a total rebuild of my system over the course of the last few days. When complete, I evoked su from koqueror and did 'env-update && source /etc/profile' then rebooted. When I got back into my KDE environment, low and behold... my su problem had been resolved and is now functioning as expected.

I still have no idea how it got messed up, nor do I have any idea how exactly it resolved itself, but in any event it's now resolved. So I'm marking this thread as solved. Thanks again to all of you who responded.

----------

