Any time I try to run a command located in /sbin or /usr/sbin using
sudo, like “sudo ifconfig” or “sudo tail -f /var/log/messages”, it comes
back with “command not found”. If I perform a “sudo -i” and drop to a
root shell that way, the commands work fine. My sudoers file is as
follows:
Code:
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”
User privilege specification
root ALL=(ALL) ALL
normaluser ALL=(ALL) ALL
On my older Debian system my sudoers file looks exactly like this and I
have no problems running privileged commands using sudo on that box.
If I run sudo /usr/bin/env path on both machines, the relevant
variables are identical on both machines. Why can’t I run privileged
shell commands using sudo in 11.1?
Hi
Maybe on the Deb system the user/system profile in /etc adds the /sbin
and /usr/sbin paths to your environment. Or maybe the files exist
in /usr/sbin on the Deb system and on openSUSE they are in /sbin?
I would update your ~/.profile to update your PATH variable.
–
Cheers Malcolm °¿° (Linux
Counter #276890) openSUSE 11.1 x86 Kernel 2.6.27.7-9-default
up 9:03, 2 users, load average: 0.15, 0.09, 0.11
GPU GeForce 6600 TE/6200 TE - Driver Version: 180.22
/sbin and /usr/sbin aren’t found in either of those.
On my SUSE box, here is what I get if I run sudo env:
Code:
PATH=/usr/sbin:/bin:/usr/bin:/sbin
which means that at least in theory, I should be able to type just
command names and not absolute paths and they should run. If I run
“sudo /sbin/ifconfig” it works, but that’s clumsy. Adding /sbin and
/usr/sbin to my path isn’t a desired solution because then I can just
run any privileged command as user, which defeats the purpose of them
being privileged (and means that both sudo and su are now unnecessary
for read access; I’d only need them if I wanted to make changes).
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
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:
Code:
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:~>
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!
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
Code:
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.
mightyteegar;1929155 Wrote:
> “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 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:
Code:
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:
Code:
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.
ken_yap;1929248 Wrote:
> 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:
>
> >
Code:
> > 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:
>
> >
Code:
> > 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:
Code:
$ 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.
