Terminal Path Command - echo $PATH - What Do You Know About Your PATH?

English Install/Boot/Login
#1

So I have been wondering just what might be going on that some commands work as a normal user while others only work as root and still others only work as a certain type of root. Also, I might add that any time we provide a command to someone else that requires you to be root, we need to indicate the kind of root command, because there is a difference. (The issue of needing to be root has to do with system wide modifications and the need for tight security, a subject that is outside the scope of this message today.)

For instance look at the terminal command:

fdisk -l
Absolute path to 'fdisk' is '/sbin/fdisk', so running it may require superuser privileges (eg. root).

Open a terminal session and type this command and you are told of its location and that you might need to be root to get it to run. Humm, OK then how about this:

sudo fdisk -l
root's password:
sudo: fdisk: command not found

Still not working. So what do you think our unknowing users are thinking? What about this command:

su
Password:
fdisk -l

And Bam! I get my disk listing just as I was requesting. Humm, why does su work and sudo does not? Perhaps it has something to do with your path. So, I did a test using echo $PATH as a normal user and as different kinds of root and here is what I found:

Using echo $PATH

With or Without using sudo (echo $PATH<enter> or sudo echo $PATH<enter>)

01) /usr/lib64/mpi/gcc/openmpi/bin
02) /home/james/bin
03) /usr/local/bin
04) /usr/bin
05) /bin
06) /usr/bin/X11
07) /usr/X11R6/bin
08) /usr/games
09) /opt/kde3/bin
10) /usr/lib64/jvm/jre/bin
11) /usr/sbin
12) /usr/sbin

su (su<enter> and echo $PATH<enter>)

01) /usr/lib64/mpi/gcc/openmpi/bin
02) /home/james/bin
03) /usr/local/bin
04) /usr/bin
05) /sbin
06) /bin
07) /usr/bin/X11
08) /usr/X11R6/bin
09) /usr/games
10) /opt/kde3/bin
11) /usr/lib64/jvm/jre/bin
12) /usr/sbin
13) /usr/sbin
14) /usr/sbin

su - (su -<enter> and echo $PATH<enter>)

01) /usr/lib64/mpi/gcc/openmpi/bin
02) /sbin
03) /usr/sbin
04) /usr/local/sbin
05) /root/bin
06) /usr/local/bin
07) /usr/bin:/bin
08) /usr/bin/X11
09) /usr/X11R6/bin
10) /usr/games
11) /opt/kde3/bin
12) /usr/lib64/jvm/jre/bin
13) /usr/sbin

su - root (su - root<enter> and echo $PATH<enter>)

01) /usr/lib64/mpi/gcc/openmpi/bin
02) /sbin
03) /usr/sbin
04) /usr/local/sbin
05) /root/bin
06) /usr/local/bin
07) /usr/bin
08) /bin
09) /usr/bin/X11
10) /usr/X11R6/bin
11) /usr/games
12) /opt/kde3/bin
13) /usr/lib64/jvm/jre/bin
14) /usr/sbin

So in our very first attempt to run the fdisk command, we were told the program was located in the folder /sbin/fdisk. So the only way this command worked is when we used the su command which placed the /sbin folder in our path. Now, knowing the path, we could have run the program using sudo in this way:

sudo /sbin/fdisk -l

This time, using the sudo command, the fdisk -l command works just fine. For a few other things about the path command. You can add to your path command for a single terminal session by using the following command:

PATH=${PATH}:/new/path/to/add

Close the terminal session and it is gone however. What about making it there all of the time, but for your personnel sessions only. Edit the following file, if you use KDE:

kdesu kwrite ~/.profile

And add your new path command there. So, have you learned anything about using the path command? Have I missed something you need to add (which is very likely)? Have I got anything wrong (then correct me)?

If you post a command that needs root permissions, make sure your fellow users know how to make the command work as it takes only a little more effort to show this.

Please, I welcome all comments and all points of view. Lets make this a good thread to read for everyone. Remember you can’t learn if you don’t try and you don’t fail, so that you can see the error of your ways and make the required corrections. Its the only way to learn.

I fail all of the time, even as we speak. lol!

Thank You,

#2

Use

sudo -i fdisk -l

Also note the “may” in cnf’s message. Some programs in /sbin and /usr/sbin, e.g. ifconfig, don’t require root privilege to run in certain modes, e.g. report only. I make it easy to use such programs by linking to it from ~/bin.

ln -s /sbin/ifconfig ~/bin

#3

Hi James,
Maybe you should highlight the difference between:

su
echo $PATH

and

su -l
echo $PATH
#4

Yet another way to use sudo.

sudo -i fdisk -l

It is not clear to me why -i or -s would allow this command to work. Could you expand on this ken_yap? And thanks so much for your input here.

and

please_try_again, I was thinking the explanation of the difference between su & su -l was at least one of the reasons you were here? Right?

Thank You,

#5

It reads the login files of the target user (in this case root).

#6

The command ‘sudo’ has not much in common with ‘su’.

#7

jdmcdaniel3 wrote:
> I was thinking the explanation of the difference
> between su & su -l was at least one of the reasons you were here?

su is short for substitute user, some say switch user (but it is not
for “super user”)…

remember, Linux roots are in Unix and it is born a multi-user
system…think Big Iron…a main frame in the corporation basement or
college administration building, and 1000 users scattered all
over…and one (or a hand full of) system administrators or
superusers or root(s)…

one day an administrator might get a note from Tim in Personnel that
his account is messed up and he gives instructions on how to see the
mess…that super user might then wanna see exactly what Tim sees and
at a terminal type:


su Tim

and, poof that Administrator is (as far as the machine knows) Tim!!

think switch user when you use su, that is all it is…it is NOT a
become Super User command…

except, the default behavior for su alone is to ASSUME the typing
person wants to be root…

the ‘real’ way to become root is


su root

try it!

however, when you do JUST that, with no options stated, then you
keep YOUR environment (including path)…that is if i am signed in as
me and “su root” i will remain in my home directory and the path will
remain my path…NOT root’s path…

to fully switch to root AND root’s environment it is necessary to
change the shell by using an option see “man su”…all three of these
options are synonyms for each other and will result in that change:


su --login root
su -l root
su -

entering any of those and i am magically transported to roots home
with root’s full environment…

ok so far?

now, Ken has already told you that sbin is not in the users path, so
that is why you can’t see them if you have only used su to become
root, but keep your on path…

sudo is different, (remember the mainframe) it is designed to allow
the Admin(s) to give some certain LIMITED ability to do some things
that normally only a system admin can do…see


man sudo

–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

#8

Let me put something straight in your line of thinking: there is only one root, no certain types of root. As you may have found by reading the above, it depends on the way you invoke root access.

‘su’ is not restricted to root. Suppose you have 2 users, james and semaj, you’re logged in as james, but want to edit a file with the other user’s credentials:


james@machine:~>su - semaj
Password: semajspasswordhere
semaj@machine:>vi somefile

If no user argument is given, root is the default.

On a login the user’s environment variables are read, they contain the PATH.

#9

@Knurpht, you’re not just writing in English, German, French and Dutch. Now you’re writing in verlan as well. :wink:
Verlan - Wikipedia, the free encyclopedia

#10

If you are confused on who you are you can do a whoami command

#11

Wow, looks like we got a lot of good responses here. I think that we have started talking a lot about how to gain root permissions and not so much about your path. I would also like to clarify that there is only one root, but different ways to obtain root authority to execute certain commands. When we say take on the root environment, we must be including the path of root as well.

The sudo command gives us the authority to run privileged commands, but does not by default give us the root environment.

The su command also gives us the authority to run privileged commands and does by default provide us much of the root environment. Certainly su puts the /sbin folder in the path to run such commands as fdisk.

Now since this thread is about the path, did you notice how the paths changed depending on how root access was being obtained? Did you also notice that the su command, used alone, had three folder paths, added at the end, that are all the same? In fact, the path /usr/sbin can appear more than once in a lot of places. I wonder why that might be true?

When we talk about the root environment, what besides authority to run privileged commands, different paths and perhaps a different “home” folder do we get as root? Anyone up to the task to spell it all out? Look at the very detailed message we got from DenverD. That is what I want to see here.

Thank You,

#12

gogalthorp wrote:
> If you are confused on who you are you can do a whoami command

LOL!

–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

#13

well … again, try the following:

su
echo $USER

and

su -l
echo $USER

Do you see a difference ?

If you’re still not convinced, try

su
set > /tmp/env_user

and

su -l
set > /tmp/env_root

then compare the files /tmp/env_user and /tmp/env_root

 diff /tmp/env_user /tmp/env_root
#14

Yep, that too. :wink:

#15

jdmcdaniel3 wrote:
> The su command also gives us the authority to run privileged commands
> and does by default provide us much of the root environment.

nope…if by “The su command” you mean, as yourself you type this in a
terminal:


su

that gives you NOT one little bit of the root environment as you stated…

instead “su” alone leaves you with your own user environment…you
have shown that to yourself already by posting the results of


su (su<enter> and echo $PATH<enter>)
su - (su -<enter> and echo $PATH<enter>)

“su” alone will always default to root powers but keep the
environment of the user switched from, while “su -” (or “su -l” or “su
–login”) will always give you root powers AND root’s environment…

now, if you as a user, issue this:


su -

you will MOVE from where ever you were to /root
then, if you do this


su [your ID]

you will revert to your user powers, but remain in /root and with
root’s environment…

but if you as root enter:


su - [your ID]

you will become you, with your powers and your environment…and, be
back in your /home/[your ID]

and, the same would happen if you did either of these also:


su -l [your ID]
su --login

see?

–
DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

#16

Now I seem to have some statements being made that are not true. That is, that the su command, by its self does not provide any of the root environment. But if you look at my path commands, it is changed when you use just su, as in particular, the /sbin path is present. Look at the Path listing for using su one more time.

su (su<enter> and echo $PATH<enter>)

01) /usr/lib64/mpi/gcc/openmpi/bin
02) /home/james/bin
03) /usr/local/bin
04) /usr/bin
05) /sbin
06) /bin
07) /usr/bin/X11
08) /usr/X11R6/bin
09) /usr/games
10) /opt/kde3/bin
11) /usr/lib64/jvm/jre/bin
12) /usr/sbin
13) /usr/sbin
14) /usr/sbin

Also, lets talk about where the path command is being set. I find that as a user, you can change your path in the following two files if you wanted to. (~ = /home/yourname)

~/.bashrc
~/.profile

I find that the path is being set for you in the following files where it is NOT recommended you make any changes:

/etc/profile.d/profile.sh
/etc/bash.bashrc
/etc/profile

Further, I found a suggestions that as root, you could create a file called:

/etc/profile.local

Which could be used to modify all paths in the system, added to those that exist for instance. Does any of this sound correct?

Thank You,

#17

Incidentally the way su - (and ssh) cause the target user’s environment to be initialised is, after changing uid to the target user, call the shell with -l, or by an older convention, pass a dash as the first character of argv[0], which normally contains the name (not the executable path) of the program. Either of these actions cause the shell to read some init files that are normally not when run as a non-login shell. And PATH is usually one of the things set in one of those config files. You can read all the gory details under INVOCATION in man bash. That by the way is where you should read to understand which initialisations go into which init file.

#18

Yes, that’s what I do too. Be aware that it is only sourced in login shells, as ken_yap just explained.

Here’s an example of redefining PATH in /etc/profile.local:


localbase=/usr/local

pathmunge () {
    if ! echo $PATH | /bin/egrep -q "(^|:)$1($|:)" ; then
	if  -d $1 ] ; then	
   	    if  "$2" = "after" ] ; then
        	PATH=$PATH:$1
       	    else
        	PATH=$1:$PATH
	    fi
       fi
    fi
}

# make path more comfortable

pathmunge	$localbase/bat
pathmunge	$HOME/bin

if grep -q "wheel.*$USER" /etc/group ; then
pathmunge	/usr/sbin after
pathmunge	/sbin after
pathmunge	/usr/local/sbin after
fi
#19

First, I’d like to say how cool this thread is.

Since installing 11.3, I’d noticed little things about not finding myself in the expected directory location when su, sudo and logging in as root and this thread goes a long ways towards answering those mysteries. I don’t remember these types of issues in 11.1 and earlier, has something changed and if so when? The only thing that looks familiar is in post #16 re suggested use creating a profile.local if you want to make any PATH changes persistent.

I’m also disappointed that if implementing sudo instead of su (or su root) is supposed to be a significant security measure that it only requires an explicit path to access the /sbin/ folder and possibly other locations which you might want off limits. Is there a permissions issue beyond the scope of this thread (covering only $PATH)?

Hoping I’m not getting too off -thread, I did a quick lookup of “su vs sudo” and the Wikipedia entry says that the file /etc/sudoers determines the environment and permissions of sudo. Inspecting that file on my default 11.3, unless I’m missing something although the environment is an alias of the ordinary user, the permissions are absolutely no different than root.

So, what then really is the security advantage of using sudo instead of su?

Thx,
Tony

#20

Putting programs in /sbin or /usr/sbin is not a security measure. Programs still do their own checking that your uid is really 0. You can run all the programs you like in /sbin or /usr/sbin as yourself and it will not get you any enhanced privileges.

The segregation is more to do with classification of a program as an admin tool or not. But some distros choose to add /sbin and /usr/sbin to normal users’ paths so that sudo fdisk -l works as expected.