They are perfectly identical. I just reinstalled sudo on SUSE and copied my /etc/sudoers file straight from the Debian box to my SUSE box. Still no luck.
Meh, guess I’ll just have to stick with sudo -i for now… oh, how I hate extra typing 
Hi
I wonder if the differences are in the /etc/permission* files…
–
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.1 x86 Kernel 2.6.27.7-9-default
up 10:04, 2 users, load average: 0.17, 0.15, 0.18
GPU GeForce 6600 TE/6200 TE - Driver Version: 180.22
Hm, never seen those before. Debian doesn’t use them. I will look into that.
I have no idea what I am talking about :shame: , but instead of the line you have:
I have
root ALL=(ALL) SETENV: ALL
Is this of any use?
That didn’t work. Didn’t expect it to – that just allows root to override environment variable restrictions.
But I’m curious now – Henk, does your sudo work like it’s supposed to? If so, can you post your sudoers file?
Here it is:
boven:~ # cat /etc/sudoers
# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#
# Host alias specification
# User alias specification
# Cmnd alias specification
# Defaults specification
# Prevent environment variables from influencing programs in an
# unexpected or harmful way (CVE-2005-2959, CVE-2005-4158, CVE-2006-0151)
Defaults always_set_home
Defaults env_reset
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
# Comment out the preceding line and uncomment the following one if you need
# to use special input methods. This may allow users to compromise the root
# account if they are allowed to run commands without authentication.
#Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE XMODIFIERS GTK_IM_MODULE QT_IM_MODULE QT_IM_SWITCHER"
# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
# Runas alias specification
# User privilege specification
root ALL=(ALL) SETENV: ALL
# Uncomment to allow people in group wheel to run all commands
# and set environment variables.
# %wheel ALL=(ALL) SETENV: ALL
# Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: SETENV: ALL
# Samples
# %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users localhost=/sbin/shutdown -h now
boven:~ #
But I must add that i did say on purpose that I have no idea what I am talking about. I do not use sudo myself. I have “Terminal Program (in system management mode)” in my panel and use that one normaly because mostly I do want to do more then one statement as root.
But for a test I did:
henk@boven:~> sudo ls /
Wachtwoord:
bin dev help lib media opt root srv tmp var
boot etc home lost+found mnt proc sbin sys usr
henk@boven:~>
So it seems to work for me.
Hope this helps.
Right, ls also works for me; any command I can normally run as my regular account works. It’s only files in /sbin and /usr/sbin that don’t work. Superuser terminal might be the best way to go.
I’ll call it a day on this one. Thanks for all your help!
And right you are:
henk@boven:~> sudo modinfo
Wachtwoord:
sudo: modinfo: command not found
henk@boven:~>
And look at this one:
henk@boven:~> sudo echo $PATH
/opt/kde3/bin:/home/henk/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin
henk@boven:~>
No /sbin there. The PATH is still “my” PATH. I do not know if this is correct (as said, I never realy studied sudo).
But I always stick to
su -
(mind the** - **) or a real log in (as with the terminal) because it gives root its own environment. Much better for scurity. The user PATH can contain all sorts of places (like **./ **) where a program may have the same name as a tool you want to use as root!
“sudo echo $PATH” will return the PATH of whatever account you called sudo from, on any system. I don’t exactly know why, but it does. A better approach is “sudo env” which will give you all the vars for a sudo environment.
This has definitely been a learning experience. Anyway, sudo -i lets me accomplish anything I need to without hassle, so I’ll just stick with that because my root password is incredibly ridiculous and very hard to type
It seems that you think it is all a bit magical, but believe me there no magic in computers whatsoever. :disapointed:
As said I did not study sudo because I do not use it.
You use it, for me this implies you studied it. That is, you read the man page. It now apears you did not, so I did. 
-i
The -i (simulate initial login) option runs the shell specified in the passwd (5) entry of the user that the command is being run as. The command name argument given to the shell begins with a `-’ to tell the shell to run as a login shell. sudo attempts to change to that user’s home directory before running the shell. It also initializes the environment, leaving TERM unchanged, setting HOME, SHELL, USER, LOGNAME, and PATH, and unsetting all other environment variables. Note that because the shell to use is determined before the sudoers file is parsed, a runas_default setting in sudoers will specify the user to run the shell as but will not affect which shell is actually run.
So that is the same as the - in the su commando.
And yes that explaines very clear why you have the PATH (and more) of the user you call sudo from when you do not use the -i option. And you have the PATH (and other things) of root when you do use the -i option.
Again, IMHO, it is very useful to use the -i option. Not only for security (see my first post), but also very practical because it is very handy to have roots’ PATH (with /sbin, etc.) as you already found out.
So it is as designed and as documented and of course so in all Linux distibutions (and all Unix’s).
Trust me, I know computers are anything but magical, and if they are then it’s all black magic.
Re: the sudo man page: Oh, I have read it. I’ve read it and read it and then read it some more, and I’ve read hundreds of webpages on it as well. What none of it answers is my original question:
**Why can I “sudo ifconfig” successfully in Debian but not in openSUSE, with identical sudoers files, when neither has /sbin in my PATH and when “sudo env” returns almost identical variables on both (the differences are minor and irrelevant)? **
As for sudo -i, you don’t use that when you run a single command; you invoke it to use root’s shell. You can’t “sudo -i commandname”.
OK, I think I figured it out. Turns out Debian’s sudo implementation actually appears to be broken, and SUSE’s sudo is obeying the rules, so to speak. Now I just need to string together the right flags and options in sudoers and I think I can make it happen.
Set an alias in my .zshrc as follows:
alias sudo=“PATH=$PATH:/sbin:/usr/sbin sudo”
Hacky, but it works. Thanks to everyone who contributed!
This has nothing to do with sudo but an understanding of the shell (bash or sh) would have explained it. The expansion of $PATH happens before the command is executed. So what sudo received was:
echo /usr/local/bin:/bin:/usr/bin:...
or whatever the value of PATH happened to be at the point of call,which would be the current user’s PATH. Now to get the expansion happening after sudo has started the program, you need one level of quoting:
sudo sh -c 'echo $PATH'
will show the target user’s (root’s) path. Or, as you have discovered, use env.
Now, for extra marks, you can explain why sh -c sudo is needed instead of just echo. 
Easy, you’re executing a subshell as root, which happens after sudo resets the environment, you’re still not going to see root’s path unless you comment out “Defaults env_reset” in /etc/sudoers.
As a side note, if you use double quotes (") it will still replace the $PATH with the current one before executing sh as root.
Nope, it’s obvious you didn’t try the experiment. In fact you get:
$ sudo echo '$PATH'
$PATH
The reason is that sudo execs the command directly without invoking sh. So $PATH is not expanded by anything. That’s why you need a sh -c in between to demonstrate that $PATH has indeed changed to that of root.
Mind you, the sh -c is only needed to show that $PATH has changed. If you were running a command from sudo, you wouldn’t need the sh -c.
It is now proven that I had to study sudo even more. I am glad I appologised in the beginning for knowing not to much about sudo.
But mea culpa :shame: that I did not see that
sudo echo $PATH
does of course first expand and then let sudo simply execute an echo command of a fixed string as root (not something you have to run as root)
This reminds me of the foremost rule in understanding the programs you write: what code generates the assembler/compiller from your program and What does then happen on execution.
Same here: What does the shell make out of the statement and What does happen when this new statement is executed.
Again: no magic, but stupid and stubborn going through the different fases, not jumping to conclusions. :\
What, then, is the purpose of “Defaults env_reset” in /etc/sudoers? I am having a frustrating time always typing “/usr/sbin/command” for programs that DO NOT ALWAYS require root privileges. I am not comfortable typing ‘sudo -i’ for everything, either, because I forgot to quit/exit.
user@host:~> sudo sh -c 'echo $PATH'
/usr/sbin:/bin:/usr/bin:/sbin
On Mon, 22 Mar 2010 13:36:01 +0000, felipe1982 wrote for every to trash:
> kdemello;1929259 Wrote:
>> Easy, you’re executing a subshell as root, which happens after sudo
>> resets the environment, you’re still not going to see root’s path
>> unless you comment out “Defaults env_reset” in /etc/sudoers.
> What, then, is the purpose of “Defaults env_reset” in /etc/sudoers? I am
> having a frustrating time always typing “/usr/sbin/command” for programs
> that DO NOT ALWAYS require root privileges. I am not comfortable typing
> ‘sudo -i’ for everything, either, because I forgot to quit/exit.
>
>
> Code:
> --------------------
> user@host:~> sudo sh -c ‘echo $PATH’
> /usr/sbin:/bin:/usr/bin:/sbin
> --------------------
Code:
user@host:~> sudo ‘echo $PATH’
or
su -c “echo $PATH”
You use the Sudo Gui in YaST to set up Aliases (alias lists) for your
users, commands, hosts and the rules for your sudo, ie, where they may
execute or when some require passwords entry or not.
You could also use the CLI visudo but the YaST GUI is much better.
I think defaults=env_reset forces sudo to exec the root environment.
append /sbin to PATH in .profile
steps:
- run env in terminal
- take note PATH line and values
- edit .profile
- append in the text by typing the PATH and values from env
- insert or add /sbin in PATH value
- save .profile
- restart your computer