It’s a way in UNIX-like operating systems of running a command as another user without providing credentials. When an executable file is run, the kernel checks its file permissions and, if it sees a bit (known as the SUID bit) on the file, it sets the effective user id of the resultant process to the owner of the file. There is also an equivalent sgid bit for running as other groups.
A good example of why you’d want to do this, is the passwd command, which needs to do things that the user who is changing password can’t directly do themselves.
The SUID bit can be seen on a file by looking at its permission string:
ls -l /usr/bin/sudo
—s–x–x 1 root root 147044 Sep 30 2013 /usr/bin/sudo
That ‘s’ in place of the usual ‘x’ on the user permissions shows that the file has had SUID set; similarly an ‘s’ in the place of the ‘x’ on group permissions shows that the file has SGID set. If it showed an ‘S’ then this would show suid without executable being set.
In the octal chmod strings, this is represented by an extra digit at the start, which maps the suid, sgid and sticky bits. So the permissions of /usr/bin/sudo above could be signified by the octal numbers 4111 and could be set through chmod:
chmod 41111 /usr/bin/sudo
The most obvious example of SUID is in the sudo program – this is SUID root, so allows some users to run commands as root (or any other user) depending on its configuration.
The flaw with SUID executables should be obvious: what if the coder hasn’t done a good job and there’s a vulnerability in it? Then, if you can exploit it, you can run code with an effective user id of root (and once euid is set you can change your real uid) and it’s basically game over.
Of special note, especially to this situation, is the status of SUID and shell scripts: on most modern (i.e. this millennium) shell interpreters, when they are used they will drop privileges and never run at the higher privilege. This is to minimise the risks from the file being edited.