This may seem strange because the shell cannot know root's PATH nor it can read /etc/sudoers and such. If some_command is somewhere in sbin, some_com tab won't find it. The shell has PATH in its environment, it can read it, so if you type another_com and hit tab, it can give you a hint of another_command found somewhere according to your PATH. Take Bash as an example shell with this functionality. Tab completion deserves some explanation. Populating your PATH with all these sbin directories would only litter your tab completion (e.g.
#Debian 10 sudo command not found full
But if you do want it anyway, just use its full path and get it ( whereis some_command may be useful). Your user account is not set up to run some_command without sudo because as a normal user you don't need it. or the file runs successfully because you can run it despite it being in sbin (e.g.the file runs and uses some authentication agent to elevate permissions without sudo (such a file would most likely be placed in bin in the first place, example: /bin/systemd).the file runs but it cannot get access to essential resources, so it throws an error and exits (e.g.
the file permissions may disallow non-root users to run it (although in Debian 9 many (all?) system executables can be run by any user).Or they can use a full path like /sbin/some_command. Any user can add all these sbin directories to their own PATH, so after typing some_command the shell will try to run the executable. So if sudo some_command finds the executable and sole some_command doesn't, it's because some_command resides in one of directories that are in secure_path but not in your PATH.īut this is not a security feature. In these directories there are tools intended to be used mostly by root. Note that PATH for root and secure_path used by sudo contain few directories named sbin (in different locations), while PATH for regular user doesn't. (This is somewhat simplified, other options may alter this mechanics see man 5 sudoers for details). If it's not explicitly defined, /etc/sudoers says the default value is secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" This set may or may not be defined somewhere in sudo config ( /etc/sudoers, /etc/sudoers.d/*). When you run sudo some_command, sudo uses yet another set of directories instead of PATH. Usually ~/.profile is a good file do do so. I call it "default" because normally /etc/profile gets loaded for any user, but then the user can alter their own PATH. (directories are separated by :) and for any other user it's PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" This means for any user with UID 0 (in my Debian only for root) the default is PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" In my Debian 9 the file /etc/profile defines basic PATH like this: if then
An executable can be run by its sole name if it's found in one of the directories specified by PATH environment variable.
0 kommentar(er)
