su identification

[Duncan]

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.