https://qa.mandrakesoft.com/show_bug.cgi?id=448
------- Additional Comments From [EMAIL PROTECTED] 2003-02-22 22:20 ------- *** Bug 2151 has been marked as a duplicate of this bug. *** ------- Additional Comments From [EMAIL PROTECTED] 2003-02-23 11:29 ------- After seeing Bug 2151 being marked dup of this one, I wanted to comment a bit. As an little side-point, Debian Woody has solved this in an interesting way: I am not completely sure how, but it seems that they manipulate the search path *only* for the command being executed by sudo itself, not the PATH variable for the resulting shell/command. Working on both systems daily, I can only say, sudo not searching */sbin is indeed a major PITA. I would like to reopen the bug (which I unable to do, it seems) with the request to get at least SECURE_PATH working which it does not for me (using tcsh, but same result with bash and sh): $ env PATH=/bin SECURE_PATH=/sbin /usr/bin/sudo /bin/env | grep '^PATH' PATH=/bin Sorry, if I am simply ignorant and using it the wrong way, but IIRC I read somewhere that SECURE_PATH requires some compile time configure option in order to work. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------- Reminder: ------- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: if you were to issue the command "sudo echo $PATH" you will see that the path givin is NOT root's. This gets very annoying since the whole point of sudo is mostly to run commands as root, and for me alot of them are only in root's path. I grabbed the tarball from the website and did the generic ./configure && make, then I issued the same command using the newly built binary and all was fixed. I noticed in your spec file you define some flags for ./configure, i didnt use any when i built the binary from source. Perhaps one of those is screwing it up.
