I keep running lb build, fixing problem after problem and then running it again, and now i'm getting this message:
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 1 expected program not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists... Done
Building dependency tree... Done
I then went to check my path and i see
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
This clearly shows /usr/local/sbin, /usr/sbin, and /sbin.
Any suggestions?
**UPDATE 1**
Followed this guide
http://ubuntuforums.org/showthread.php?t=1449322
every command ran fine but still the same error message after running lb build again.
**UPDATE 2 -- Additional Info**
root#kali:~# ls -lA /sbin
(Other files)
-rwxr-xr-x 1 root root 28208 Aug 12 15:00 start-stop-daemon
First, you must check the feedback information from the first line (although it is just a warning).
Then， you must have understand that the warning is the key. All the mistakes are caused by this warning. You have to add start-stop-daemon to your pc.
According to the following:
cd /tmp
wget http://developer.axis.com/download/distribution/apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
tar zxf apps-sys-utils-start-stop-daemon-IR1_9_18-2.tar.gz
cd apps/sys-utils/start-stop-daemon-IR1_9_18-2/
gcc start-stop-daemon.c -o start-stop-daemon
cp start-stop-daemon /usr/local/bin/start-stop-daemon
Now you can help yourself，and others
I have the same problem, according to https://debianforum.de/forum/viewtopic.php?f=34&t=155279 (in german) the only known solution is to run sudo lb clean before sudo lb build.
[root#c0002242 lfeng]# tar -zxvf /opt/test/ALLscripts.tar.gz -C /opt/test1
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
Could you please help me on this ?
Run the command
$ file ALLscripts.tar.gz
Compare the output, if it's gzip (as shown below) then use unzip tool to extract it
$ ALLscripts.tar.gz: gzip compressed data,from Unix
I was facing this error because my file was not downloaded yet and I was trying to extract it :).
I'm trying to monitor actual URLs, and not only hosts, with Nagios, as I operate a shared server with several websites, and I don't think its enough just to monitor the basic HTTP service (I'm including at the very bottom of this question a small explanation of what I'm envisioning).
(Side note: please note that I have Nagios installed and running inside a chroot on a CentOS system. I built nagios from source, and have used yum to install into this root all dependencies needed, etc...)
I first found check_url, but after installing it into /usr/lib/nagios/libexec, I kept getting a "return code of 255 is out of bounds" error. That's when I decided to start writing this question (but wait! There's another plugin I decided to try first!)
After reviewing This Question that had almost practically the same problem I'm having with check_url, I decided to open up a new question on the subject because
a) I'm not using NRPE with this check
b) I tried the suggestions made on the earlier question to which I linked, but none of them worked. For example...
./check_url some-domain.com | echo $0
returns "0" (which indicates the check was successful)
I then followed the debugging instructions on Nagios Support to create a temp file called debug_check_url, and put the following in it (to then be called by my command definition):
#!/bin/sh
echo `date` >> /tmp/debug_check_url_plugin
echo $* /tmp/debug_check_url_plugin
/usr/local/nagios/libexec/check_url $*
Assuming I'm not in "debugging mode", my command definition for running check_url is as follows (inside command.cfg):
'check_url' command definition
define command{
command_name check_url
command_line $USER1$/check_url $url$
}
(Incidentally, you can also view what I was using in my service config file at the very bottom of this question)
Before publishing this question, however, I decided to give 1 more shot at figuring out a solution. I found the check_url_status plugin, and decided to give that one a shot. To do that, here's what I did:
mkdir /usr/lib/nagios/libexec/check_url_status/
downloaded both check_url_status and utils.pm
Per the user comment / review on the check_url_status plugin page, I changed "lib" to the proper directory of /usr/lib/nagios/libexec/.
Run the following:
./check_user_status -U some-domain.com.
When I run the above command, I kept getting the following error:
bash-4.1# ./check_url_status -U mydomain.com
Can't locate utils.pm in #INC (#INC contains: /usr/lib/nagios/libexec/ /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5) at ./check_url_status line 34.
BEGIN failed--compilation aborted at ./check_url_status line 34.
So at this point, I give up, and have a couple of questions:
Which of these two plugins would you recommend? check_url or check_url_status?
(After reading the description of check_url_status, I feel that this one might be the better choice. Your thoughts?)
Now, how would I fix my problem with whichever plugin you recommended?
At the beginning of this question, I mentioned I would include a small explanation of what I'm envisioning. I have a file called services.cfg which is where I have all of my service definitions located (imagine that!).
The following is a snippet of my service definition file, which I wrote to use check_url (because at that time, I thought everything worked). I'll build a service for each URL I want to monitor:
###
# Monitoring Individual URLs...
#
###
define service{
host_name {my-shared-web-server}
service_description URL: somedomain.com
check_command check_url!somedomain.com
max_check_attempts 5
check_interval 3
retry_interval 1
check_period 24x7
notification_interval 30
notification_period workhours
}
I was making things WAY too complicated.
The built-in / installed by default plugin, check_http, can accomplish what I wanted and more. Here's how I have accomplished this:
My Service Definition:
define service{
host_name myers
service_description URL: my-url.com
check_command check_http_url!http://my-url.com
max_check_attempts 5
check_interval 3
retry_interval 1
check_period 24x7
notification_interval 30
notification_period workhours
}
My Command Definition:
define command{
command_name check_http_url
command_line $USER1$/check_http -I $HOSTADDRESS$ -u $ARG1$
}
The better way to monitor urls is by using webinject which can be used with nagios.
The below problem is due to the reason that you dont have the perl package utils try installing it.
bash-4.1# ./check_url_status -U mydomain.com Can't locate utils.pm in #INC (#INC contains:
You can make an script plugin. It is easy, you only have to check the URL with something like:
`curl -Is $URL -k| grep HTTP | cut -d ' ' -f2`
$URL is what you pass to the script command by param.
Then check the result: If you have an code greater than 399 you have a problem, else... everything is OK! THen an right exit mode and the message for Nagios.
I had a problem this morning deploying an application with capistrano.
# git push
# cap deploy:setup
Something strange happened and than I wasn't able to ssh to my host anymore.
Technical staff says (in Italian): "the commands you have run overwrote the shell binaries causing the system to be no more usable". Two options: I am a stupid, or they are wrong.
Here's the shell output on cap:deploy and then the error on ssh. Once the system (VPS) has been rebooted, I wasn't able to ssh anymore.
Any ideas?
mattia#desktop:/var/www/rails/my_application$ git push
Counting objects: 239, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (191/191), done.
Writing objects: 100% (202/202), 379.77 KiB, done.
Total 202 (delta 44), reused 0 (delta 0)
To ssh://mattia#my_application.it/~/git/my_application.git
96c1f19..3cc9e1c master -> master
mattia#desktop:/var/www/rails/my_application$ cap deploy:setup
* executing `deploy:setup'
* executing "mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids && chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids"
servers: ["beta.my_application.it"]
[beta.my_application.it] executing command
** [out :: beta.my_application.it]
** [out :: beta.my_application.it] malloc: ../bash/parse.y:2823: assertion botched
** [out :: beta.my_application.it] nunits < 30
** [out :: beta.my_application.it] Aborting...
command finished
failed: "env PATH=/usr/local/bin:/usr/bin:/bin GEM_PATH=/var/lib/gems/1.9.1 sh -c 'mkdir -p /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids && chmod g+w /var/www/rails/my_application /var/www/rails/my_application/releases /var/www/rails/my_application/shared /var/www/rails/my_application/shared/system /var/www/rails/my_application/shared/log /var/www/rails/my_application/shared/pids'" on beta.my_application.it
mattia#desktop:/var/www/rails/my_application$ ssh beta.my_application.it
Linux my_application 2.6.18-194.26.1.el5.028stab079.2ent #1 SMP Fri Dec 17 19:44:51 MSK 2010 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 7 12:00:53 2011 from dynamic-adsl-xx-xx-xx-xx.------.------.it
malloc: ../bash/subst.c:4494: assertion botched
realloc: called with unallocated block argument
Aborting...Connection to beta.my_application.it closed.
The short-answer is no, unless you have other plugins that aren't standard, or someone gave you a messed up Gem. (Almost nobody bothers to validate the gem signatures.) The standard deploy:setup only creates a couple of symlinks, and directories.
It does run as root, and in theory if you were to set your variables to values (untested) such as set :deploy_to, '/bin/bash', it may damage the binary, but unless you did that, I'd say that's a non-issue.
You can debug this, without relying on a shell - by using SSH in command mode:
# ssh myuser#myserver -c 'history'
Which will dump out the history file (bash) of that user, so you can test if there's been any tampering on the server, you can also check it as root, and/or run commands such as who, last and other one-liners which give you back logs (you can also cat /var/log/messages and look for suspicious activity.
I'd say that the chance of Capistrano being responsible for this is 0 (Source: I'm the maintainer.) - but you can probably get your system back into a working state using the SHS command mode, as I mentioned above (ssh myuser#myserver -c 'aptitude install bash --force' for example)
A word to the wise, if you never figure out how this happened, erase the server and change your passwords… just use this as a method to get things back up and running. It's not a very subtle tactic, but if you've been hacked, a hacker could easily throw you out by making a user which uses an alternative shell, and corrupting yours.
It would also be a huge help from your admins, if they could give you /bin/bash - the contents of the file, so you can see if it's text, junk, corrupted binary, or something from your deploy.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
This is the PATH variable without sudo:
$ echo 'echo $PATH' | sh
/opt/local/ruby/bin:/usr/bin:/bin
This is the PATH variable with sudo:
$ echo 'echo $PATH' | sudo sh
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
As far as I can tell, sudo is supposed to leave PATH untouched. What's going on? How do I change this? (This is on Ubuntu 8.04).
UPDATE: as far as I can see, none of the scripts started as root change PATH in any way.
From man sudo:
To prevent command spoofing, sudo
checks ``.'' and ``'' (both denoting
current directory) last when searching
for a command in the user's PATH (if
one or both are in the PATH). Note,
however, that the actual PATH
environment variable is not modified
and is passed unchanged to the program
that sudo executes.
This is an annoying function a feature of sudo on many distributions.
To work around this "problem" on ubuntu I do
the following in my ~/.bashrc
alias sudo='sudo env PATH=$PATH'
Note the above will work for commands that don't reset the $PATH themselves.
However `su' resets it's $PATH so you must use -p to tell it not to. I.E.:
sudo su -p
In case someone else runs accross this and wants to just disable all path variable changing for all users.
Access your sudoers file by using the command:visudo. You should see the following line somewhere:
Defaults env_reset
which you should add the following on the next line
Defaults !secure_path
secure_path is enabled by default. This option specifies what to make $PATH when sudoing. The exclamation mark disables the feature.
PATH is an environment variable, and as such is by default reset by sudo.
You need special permissions to be permitted to do this.
From man sudo
-E The -E (preserve environment) option will override the env_reset
option in sudoers(5)). It is only available when either the match-
ing command has the SETENV tag or the setenv option is set in sudo-
ers(5).
Environment variables to be set for the command may also be passed on
the command line in the form of VAR=value, e.g.
LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command
line are subject to the same restrictions as normal environment vari-
ables with one important exception. If the setenv option is set in
sudoers, the command to be run has the SETENV tag set or the command
matched is ALL, the user may set variables that would overwise be for-
bidden. See sudoers(5) for more information.
An Example of usage:
cat >> test.sh
env | grep "MYEXAMPLE" ;
^D
sh test.sh
MYEXAMPLE=1 sh test.sh
# MYEXAMPLE=1
MYEXAMPLE=1 sudo sh test.sh
MYEXAMPLE=1 sudo MYEXAMPLE=2 sh test.sh
# MYEXAMPLE=2
update
man 5 sudoers :
env_reset If set, sudo will reset the environment to only contain
the LOGNAME, SHELL, USER, USERNAME and the SUDO_* vari-
ables. Any variables in the caller's environment that
match the env_keep and env_check lists are then added.
The default contents of the env_keep and env_check
lists are displayed when sudo is run by root with the
-V option. If sudo was compiled with the SECURE_PATH
option, its value will be used for the PATH environment
variable. This flag is on by default.
So may need to check that this is/is not compiled in.
It is by default in Gentoo
# ( From the build Script )
....
ROOTPATH=$(cleanpath /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin${ROOTPATH:+:${ROOTPATH}})
....
econf --with-secure-path="${ROOTPATH}"
Looks like this bug has been around for quite a while! Here are some bug references you may find helpful (and may want to subscribe to / vote up, hint, hint...):
Debian bug #85123 ("sudo: SECURE_PATH still can't be overridden") (from 2001!)
It seems that Bug#20996 is still present in this version of sudo. The
changelog says that it can be overridden at runtime but I haven't yet
discovered how.
They mention putting something like this in your sudoers file:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin"
but when I do that in Ubuntu 8.10 at least, it gives me this error:
visudo: unknown defaults entry `secure_path' referenced near line 10
Ubuntu bug #50797 ("sudo built with --with-secure-path is problematic")
Worse still, as far as I can tell, it
is impossible to respecify secure_path
in the sudoers file. So if, for
example, you want to offer your users
easy access to something under /opt,
you must recompile sudo.
Yes. There needs to be a way to
override this "feature" without having
to recompile. Nothing worse then
security bigots telling you what's
best for your environment and then not
giving you a way to turn it off.
This is really annoying. It might be
wise to keep current behavior by
default for security reasons, but
there should be a way of overriding it
other than recompiling from source
code! Many people ARE in need of PATH
inheritance. I wonder why no
maintainers look into it, which seems
easy to come up with an acceptable
solution.
I worked around it like this:
mv /usr/bin/sudo /usr/bin/sudo.orig
then create a file /usr/bin/sudo containing the following:
#!/bin/bash
/usr/bin/sudo.orig env PATH=$PATH "$#"
then your regular sudo works just like the non secure-path sudo
Ubuntu bug #192651 ("sudo path is always reset")
Given that a duplicate of this bug was
originally filed in July 2006, I'm not
clear how long an ineffectual env_keep
has been in operation. Whatever the
merits of forcing users to employ
tricks such as that listed above,
surely the man pages for sudo and
sudoers should reflect the fact that
options to modify the PATH are
effectively redundant.
Modifying documentation to reflect
actual execution is non destabilising
and very helpful.
Ubuntu bug #226595 ("impossible to retain/specify PATH")
I need to be able to run sudo with
additional non-std binary folders in
the PATH. Having already added my
requirements to /etc/environment I was
surprised when I got errors about
missing commands when running them
under sudo.....
I tried the following to fix this
without sucess:
Using the "sudo -E" option - did not work. My existing PATH was still reset by sudo
Changing "Defaults env_reset" to "Defaults !env_reset" in /etc/sudoers -- also did not work (even when combined with sudo -E)
Uncommenting env_reset (e.g. "#Defaults env_reset") in /etc/sudoers -- also did not work.
Adding 'Defaults env_keep += "PATH"' to /etc/sudoers -- also did not work.
Clearly - despite the man
documentation - sudo is completely
hardcoded regarding PATH and does not
allow any flexibility regarding
retaining the users PATH. Very
annoying as I can't run non-default
software under root permissions using
sudo.
This seemed to work for me
sudo -i
which takes on the non-sudo PATH
I think it is in fact desirable to have sudo reset the PATH: otherwise an attacker having compromised your user account could put backdoored versions of all kinds of tools on your users' PATH, and they would be executed when using sudo.
(of course having sudo reset the PATH is not a complete solution to these kinds of problems, but it helps)
This is indeed what happens when you use
Defaults env_reset
in /etc/sudoers without using exempt_group or env_keep.
This is also convenient because you can add directories that are only useful for root (such as /sbin and /usr/sbin) to the sudo path without adding them to your users' paths. To specify the path to be used by sudo:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin"
Works now using sudo from the karmic repositories. Details from my configuration:
root#sphinx:~# cat /etc/sudoers | grep -v -e '^$' -e '^#'
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/grub-1.96/sbin:/opt/grub-1.96/bin"
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
root#sphinx:~# cat /etc/apt/sources.list
deb http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe
deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe
deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe
deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe
deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted universe
root#sphinx:~#
root#sphinx:~# cat /etc/apt/preferences
Package: sudo
Pin: release a=karmic-security
Pin-Priority: 990
Package: sudo
Pin: release a=karmic-updates
Pin-Priority: 960
Package: sudo
Pin: release a=karmic
Pin-Priority: 930
Package: *
Pin: release a=jaunty-security
Pin-Priority: 900
Package: *
Pin: release a=jaunty-updates
Pin-Priority: 700
Package: *
Pin: release a=jaunty
Pin-Priority: 500
Package: *
Pin: release a=karmic-security
Pin-Priority: 450
Package: *
Pin: release a=karmic-updates
Pin-Priority: 250
Package: *
Pin: release a=karmic
Pin-Priority: 50
root#sphinx:~# apt-cache policy sudo
sudo:
Installed: 1.7.0-1ubuntu2
Candidate: 1.7.0-1ubuntu2
Package pin: 1.7.0-1ubuntu2
Version table:
*** 1.7.0-1ubuntu2 930
50 http://au.archive.ubuntu.com karmic/main Packages
100 /var/lib/dpkg/status
1.6.9p17-1ubuntu3 930
500 http://au.archive.ubuntu.com jaunty/main Packages
root#sphinx:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin
root#sphinx:~# exit
exit
abolte#sphinx:~$ echo $PATH
/home/abolte/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/chromium-17593:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/xpra-0.0.6/bin
abolte#sphinx:~$
It's wonderful to finally have this solved without using a hack.
# cat .bash_profile | grep PATH
PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
export PATH
# cat /etc/sudoers | grep Defaults
Defaults requiretty
Defaults env_reset
Defaults env_keep = "SOME_PARAM1 SOME_PARAM2 ... PATH"
Just comment out "Defaults env_reset" in /etc/sudoers
Just edit env_keep in /etc/sudoers
It looks something like this:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"
Just append PATH at the end, so after the change it would look like this:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"
Close the terminal and then open again.
Secure_path is your friend, but if you want to exempt yourself from secure_path just do
sudo visudo
And append
Defaults exempt_group=your_goup
If you want to exempt a bunch of users create a group, add all the users to it, and use that as your exempt_group. man 5 sudoers for more.
the recommended solution in the comments on the OpenSUSE distro suggests to change:
Defaults env_reset
to:
Defaults !env_reset
and then presumably to comment out the following line which isn't needed:
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"
comment out both "Default env_reset" and "Default secure_path ..." in /etc/sudores file works for me
You can also move your file in a sudoers used directory :
sudo mv $HOME/bash/script.sh /usr/sbin/
Er, it's not really a test if you don't add something to your path:
bill#bill-desktop:~$ ls -l /opt/pkg/bin
total 12
-rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
bill#bill-desktop:~$ which foo
/opt/pkg/bin/foo
bill#bill-desktop:~$ sudo su
root#bill-desktop:/home/bill# which foo
root#bill-desktop:/home/bill#
The PATH will be reset when using su or sudo by the definition of ENV_SUPATH, and ENV_PATH defined in /etc/login.defs
$PATH is an environment variable and it means that value of $PATH can differ for another users.
When you are doing login into your system then your profile setting decide the value of the $PATH.
Now, lets take a look:-
User | Value of $PATH
--------------------------
root /var/www
user1 /var/www/user1
user2 /var/www/html/private
Suppose that these are the values of $PATH for different user. Now when you are executing any command with sudo then in actual meaning root user executes that command .
You can confirm by executing these commands on terminal :-
user#localhost$ whoami
username
user#localhost$ sudo whoami
root
user#localhost$
This is the reason. I think its clear to you.
It may be counter-intuitive but the first time it happened to me, I knew what was going on. Believe me, you don't want root running someone else's PATH
"Hey root? Can you help me, something is wrong" and he comes over and sudo's from my shell and I wrote a "${HOME}/bin/ls" shell script that first gives me superuser privileges, and then calls the real /bin/ls.
# personal ls
usermod -a -G sudo ${USER}
/bin/ls
The minute root user does "sudo ls" from my shell, he's done and the box is wide open to me.