Command found only when used with `sudo` in terminal

I wouldn't call it a security feature.

An executable can be run by its sole name if it's found in one of the directories specified by PATH environment variable. In my Debian 9 the file /etc/profile defines basic PATH like this:

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

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"

(directories are separated by :) and for any other user it's

PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

I call it "default" because normally /etc/profile gets loaded for any user, but then the user can alter their own PATH. Usually ~/.profile is a good file do do so.

When you run sudo some_command, sudo uses yet another set of directories instead of PATH. This set may or may not be defined somewhere in sudo config (/etc/sudoers, /etc/sudoers.d/*). 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 is somewhat simplified, other options may alter this mechanics; see man 5 sudoers for details).

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. In these directories there are tools intended to be used mostly by root.

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.

But this is not a security feature. 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. Or they can use a full path like /sbin/some_command. Real security features then kick in:

• 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);
• the file runs but it cannot get access to essential resources, so it throws an error and exits (e.g. /sbin/hwclock);
• 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);
• or the file runs successfully because you can run it despite it being in sbin (e.g. /sbin/discover in my Debian).

Your user account is not set up to run some_command without sudo because as a normal user you don't need it. But if you do want it anyway, just use its full path and get it (whereis some_command may be useful). Populating your PATH with all these sbin directories would only litter your tab completion (e.g. in Bash).

Tab completion deserves some explanation. Take Bash as an example shell with this functionality. 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. If some_command is somewhere in sbin, some_com tab won't find it.

Still sudo some_com tab may find it. This may seem strange because the shell cannot know root's PATH nor it can read /etc/sudoers and such. What happens is the shell temporarily adds common sbin directories to PATH only to perform this search. This is done inside the file /usr/share/bash-completion/completions/sudo, the relevant line is

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

To answer your explicit question

Can I disable this feature?

Yes, you can add sbin directories to your PATH. This won't allow you to successfully run commands without sudo though, if they really need sudo (and many do).