The very quick quide to sudo. This guide is for end users.
Sudo is configured by root to allow a user to run a command as root. If a user is granted all sudo privileges, then the user can do anything. Sudo eliminates password hassles, because the user will only need to know their own passoword.
To become root, a user would type:
$ sudo su - root
The user would be prompted for their own password.
A user can list their sudo privileges with:
$ sudo -l
Users will often be granted sudo for specific commands - such as starting and stopping a service or becoming another user. In this case, the user could (for example) start or stop a web server without needing the root password.
Application software may be installed as user appowner with group appgroup. The application files will typically be group/world read so there is limited ability to accidentally delete the files. There will typically be other users with group appgroup, so the users can do most tasks with their own account. There will be times , for example application patching, when a user will need to become the application owner. The application owner password could be shared. Alternatively, users could be granted sudo permission to become the application owner.
Sudo typically is configured to log sudo access. Sometimes this is used as a security/auditing feature. When configured to write to syslog, an entry will look like:
Jun 7 10:05:22 host001 sudo: usera : TTY=pts/1 ; PWD=/home/usera ; USER=root ; COMMAND=/usr/bin/su - oracle
Be careful when relying on these logs, as the security depends on the correct functioning of the commands that are run under sudo. For example, allowing "sudo vi /etc/hosts" will allow the user to spawn a shell as root and this will not be logged.
Alternatives to sudo are using setuid and setgid (which have significant gotchas). Solaris has Role Based Access Control, which provides more granular privileges.