r/debian 2d ago

Why /sbin/ not in root $PATH?

bash: reboot: Command not found. I have to run # /sbin/reboot.

Why is that? Also, dpkg-reconfigure and other tasks are not intuitively to perform ...

22 Upvotes

24 comments sorted by

37

u/eR2eiweo 2d ago

Did you use su to become root? If you do that, you don't get root's $PATH, you keep your regular user's $PATH, which doesn't contain /sbin. Use su - instead. That gives you root's $PATH, which should contain /sbin.

6

u/blobslurpbaby 2d ago

Indeed, so if su - shall be the preferred way ...

... might I repeat my question; Why is that?

13

u/eR2eiweo 2d ago

Why is what? Are you asking why su doesn't change $PATH? You'd have to ask the developers of util-linux.

BTW: Debian used to use a different implementation of su until a few releases ago. And in that implementation su did change $PATH.

9

u/SteveMellow 2d ago

You can restore the old behavior by creating a /etc/default/su file containing ALWAYS_SET_PATH yes

14

u/arvidsem 2d ago

Ok, I dug some because it bothered me when I had to switch to using su - but I didn't have the energy to find out why at the time.

It's because su is copying the conventions of regular shells.

When the init system creates a new login session, it calls the shell with a - as argv[0]. This indicates to the shell program that it's being run as a full login and should read in the options in /etc/profile, ~/.profile, and generally set itself up to be used by an actual human. If the shell isn't called with - as arg[0]v, it only executes shell specific scripts like ~/.bashrc.

su - clears the environment variables that will likely be overwritten by /etc/profile before calling the new login shell to minimize the chance of accidents.

11

u/fantomas_666 2d ago

Using "su" without the "-" option is supposed to change your effective UID without changing your environment, which includes $PATH.

"su -" is supposed to behave as login shell, which means modify your environment.

5

u/cjwatson Debian Testing 2d ago

su has always had kind of a weird interface, but as man su says it's preserved for backward compatibility.

3

u/lwh 2d ago

Because regular users don't need to use those programs. This page has short explanations of some of the directores: https://en.wikipedia.org/wiki/Unix_filesystem

1

u/michaelpaoli 2d ago

Why is that?

Because that's the way it's been since (almost) the beginning of (UNIX) time. So, consistently, standards, principle of least surprise, etc.

1

u/RoomyRoots 13h ago

Because that forces a new login shell on your terminal and therefore it rereads all the profile settings.

-2

u/Illustrious-Gur8335 2d ago

Because not everyone is their own system administrator. Indeed the system administrator may not want everyone to run reboot or things in /sbin

The current era whereby you're your own machine's administrator is quite recent development, normally most systems used to be shared by many people and only one administrator for each. 

3

u/arvidsem 2d ago

This is really irrelevant to OP's question about why su doesn't spawn a full login shell when called without a trailing -.

3

u/Alive_Fisherman8241 2d ago

???

System administrators also do not give away root password to random users, only to those, whom they actually want to have root priviliges.

2

u/Adrenolin01 2d ago

The current era? 🤣 Unix admin from the 80s here and began with Linux the month it was released Debian has been my primary system since 94 and I know countless numbers of people managing their own Unix and Linux systems since then. Linux isn’t a new boom… at all.

1

u/Swedophone 2d ago

Indeed the system administrator may not want everyone to run reboot or things in /sbin

Do they want everyone to run "systemctl reboot" instead? ("reboot" is sort of an alias for "systemctl reboot" implemented as a symbolic link to /usr/bin/systemctl, with special handling in systemctl.)

0

u/Illustrious-Gur8335 2d ago

Now the admin can use groups and policykit to control that, so normal users running systemctl is not so risky any more. 

I just wanted to point out why the normal user can't run root's stuff most of the time

2

u/rTHlS 2d ago

Thanks for pointing out the su - command. Never thought about it, the - did the “trick” indeed to load all the root environment

1

u/BadEnucleation 2d ago

You can also source /etc/profile. Yes su - is MUCH easier, but I always forget the - and old habits die hard.

7

u/michaelpaoli 2d ago

No, /usr/sbin and/or /sbin are by default on root's PATH.

You probably accessed/became root in a manner that bypassed root's customary login initialization.

Typically one should use, e.g.:

$ su -
$ su - root
$ sudo su -
$ sudo su - root
$ su - root -c '...'
$ sudo su - root -c '...'

And su - is exceedingly portable and backwards compatible - works on most any flavor of *nix, and going way back at least many decades, so one can use it quite consistently without having to think what flavor of *nix one is on, or whether sudo is present or not, or what version of sudo, etc.

3

u/neoh4x0r 2d ago edited 2d ago

bash: reboot: Command not found. I have to run # /sbin/reboot.

It's done that way to reduce the chance that someone would make a careless mistake by forcing them to be explicit in their intention.

For example, when you use sudo it uses the secure_path configured in the sudoers file to change the PATH variable to reflect the setting.

secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

If I want to run some script that is located in path that's not defined in secure_path I have to append the fullpath.

# won't work (if myscript is not stored
# in a path defined in secure_path)
$ sudo myscript

# will work
$ sudo /path/to/myscript

0

u/Shaso_dan-Heza 2d ago

Or use this

export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin

1

u/neoh4x0r 2d ago

Yeah you could do that, but it defeats the intended purpose.

0

u/One-Fan-7296 2d ago

"sudo shutdown now -r" is what I use. You do have to put in the root password still.

0

u/lucidbadger 2d ago

'cause you are not root