Basil Fowler posted on Thu, 24 Dec 2009 13:11:45 +0000 as excerpted:
> You have confused the two commands.
>
> su means "switch user"[.] When you use su, if it has no arguments, it
> assumes that you wish to invoke the root account and will demand Root
> account's password[.] If you follow su with an account name [you] will
> will be prompted for [its] password[.] When the correct password for
> the TARGET account is entered, you will then be running as the target
> account[.]
>
> Now, with distros such as Ubuntu, the root account is disabled, so su
> does not work. A correct password (equivalent to MASTER) does not exist.
> sudo is a program that is designed to solve a difficult administrative
> problem. How do you give an ordinary user power to perform an action
> (such as managing printers) that normally requires root privileges
> without giving him /her complete control over the machine?
>
> Sudo looks up a special file - readable only by root - /etc/sudoers,
> which lists who can do what under which conditions, and allows or denies
> the desired action accordingly.
Well stated.
I look at the two commands this way:
1) su, switch user, normally requires the TARGET user's password, and
switches unconditionally to that user. If the TARGET user doesn't have a
password, it cannot normally be switched to. The exception (the the
"normally") is the traditional "root can do anything" -- IOW, root can su
to any account configured in /etc/passwd, without entering a password at
all. Of course, if said user doesn't have a shell configured in /etc/
passwd (or if the shell is set to /bin/true or /bin/false or the like, a
common tactic to disable login), then root will still have trouble su-ing
to that user.
2) sudo, super-user-do (else switch-user-do) is intended to be much more
limited than su. A user may ONLY sudo as allowed in the /etc/sudoers
file, which controls all aspects of what is allowed (which users may
sudo, what commands they may sudo, what parts of the environment are
allowed to be carried with them, whether they are prompted for a password
when they sudo, whether that password is their own or the target's
password, etc). Unlike su, typically, sudo requires the sudo-ing user's
password, NOT the target user's password. This allows said user to do
what's allowed in the sudoer's file using only their own password, thus
without having to know another one, BUT, the user can ONLY do what's
allowed in the sudoer's file.
Of course the sudoers file can and often does contain wildcards, such
that a user configured therein may be able to do anything. It can also
be configured to allow certain commands without a password, while
requiring the password for others. Also, the allowed commands can have
their parameters and options specified, so ONLY that /exact/ command,
including all parameters and options as specified, can be run, or the
configuration can be made looser, allowing a command with any parameters
and options a user cares to add.
Thus, sudo can be configured with the sudoers file to a much finer degree
than can su, which either works, allowing everything that user could do
(for root, traditionally everything, period, tho selinux with newer style
acls, access control lists, can limit even root), or doesn't work,
allowing nothing. But su requires the target password while sudo
normally only requires the sudoing user's password (tho that too can be
configured).
As Basil mentioned, sudo gets very particular about its sudoers file. If
there are any errors, it won't let you sudo at all. Thus it uses the
traditional vi* indirect editor setup. vi is short for visual editor,
and refers to the traditional Unix editor of the same name, but the vi*
commands normally honor the VISUAL and EDITOR environmental variables so
the user can specify their own editor preference. The various vi*
commands thus allow indirect editing of the system file in question,
checking format of the edited file before replacing the active one and/or
taking care of locking, to help avoid catastrophe should a mistake be
made. visudo is our command for editing the sudoers file, ensuring that
the format is correct before replacing the existing sudoers file, thus
protecting from "stupid" mistakes possibly locking out sudo entirely, if
the format is wrong. Similarly there are the vipw and vigr commands for
editing /etc/passwd and /etc/group, a vidir command for editing a
directory as if it was a file (this one I've never used), etc. Of
course, vim isn't such a command but the common form of the vi editor
itself.
Here's how I have my setup configured, as an example. I have both su and
sudo installed, tho I rarely use su for the same reason I rarely login as
root -- "don't take the name of root in vain", there's just too much
chance of fat-fingering something. Instead, I have two users configured
in sudo, my normal user, with extremely limited no-password sudo access
to rather nailed down specific commands (DEFINITELY no editors that allow
the user to shell out to bash or whatever, for instance), and an "admin"
user, allowed to do everything with no password -- almost like root, but
still requiring the sudo command to actually do stuff said user would
not /normally/ be able to do. Then, my normal user has one more allowed
command, this one WITH a password, that invokes sudo to switch to the
admin user.
This config allows my normal user to do whatever he'd normally be able to
do, plus a few specific commands (tcptraceroute, syncing my distribution
repository, etc) using sudo without a password. The normal user is also
specifically allowed to sudo to the admin user, but WITH a password. The
admin user is again allowed to do his normal stuff without sudo, but can
also sudo anything (including sudo bash, thus logging in as root),
without further passwords.
This allows me to do stuff like constructing a mkfs (that would format a
drive) command as the admin user WITHOUT the sudo command -- if I screwup
and hit enter before I'm ready, I won't damage anything. When the
command is all setup, I've double-checked that I'm operating on the
correct device, etc, I can hit enter and of course get a permissions
error, then hit the uparrow key to recall the last command, home to set
the cursor to the beginning of the command, and sudo<space> and enter, to
finally execute the command as root.
FWIW, another strategy to avoid errors at the command line, say when
deleting stuff, is to use the shell's auto-completion. In the case of
bash, this is the <tab> key. If there's just one possible completion,
it'll make it for you, if there's more than one, it'll beep and you can
hit tab a second time to get all possible completions (if there's a lot,
it'll ask you if you are sure you want to display them all, first). If
you're removing a file, using auto-completion can help you make sure you
rm the /right/ file. Combine that with the above strategy of entering
the command first as as the admin user without sudo, where it'll fail if
you try to delete system files, then going back and adding sudo, and
making a catastrophic mistake like deleting from / due to a fat-fingered
typo, becomes far harder.
Meanwhile, as usual, the manpages for su, sudo, and sudoers, should be
very helpful with the details, once you know the general idea behind the
commands, at least. The sudoers manpage in particular can be helpful in
setting up a usefully powerful but still relatively secure sudoers
config. Don't forget to use visudo for editing, to make sure the format
is correct before the file is saved! =:^)
(FWIW, there are very helpful manpages for the formats of other critical
system files as well. passwd, group, fstab, xorg.conf and inittab among
others, should all have very useful manpages. Such config file format
manpages are always section five, so for commands where the config file
is the same name as the command, man 5 command should get the config file
manual, while simply man command will normally get the command manual,
section 1 for user commands and section 8 for system commands.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
