This is one of those things you wind up not using for awhile, because most programs have the permissions that the vast majority of users want. We'll start with setting uid. What this does is let a program run as the program's owner. This is most commonly explained with the su command or the password command. On a typical Linux or BSD system, if you run ls -l /usr/bin/passwd you'll see
-rwsr-xr-x. 1 root root 33560 Apr 18 18:59 /usr/bin/passwd |
That's taken from an AlmaLinux 8.x system. FreeBSD has
| r-sr-xr-x 1 root wheel 9360 May 17 06:37 /usr/bin/passwd |
I'll use FreeBSD for the rest of my examples, as I'm writing this on a FreeBSD machine. The important thing is the s. It means the file will run with root permissions. This enables you to change your own password. (But not root's). If the permissions were changed to r-xr-xr-x, a non-privileged user wouldn't be able to change their own password. The interested user can test this, but make sure you have a root session running or you'll be locked out. If you remove the setuid, either by using chmod u-s /usr/bin/passwd or chmod 0555 /usr/bin/passwd, you'll find that a normal user won't be able to run the passwd command, even for their own account. To put it back you can use chmod u+s, or if you prefer the octal method chmod 4555. The octal value for setuid is 4, and one uses a 4 digit value rather than the usual 3 digit one. If you forget that and use chmod 455 you'll have set it owner read, group, read+write, other read+write. The other way to change it back is
chmod +4000 /usr/bin/passwd |
Using a +4000 puts on the setuid bit, without affecting whatever permissions are already on the file.
The next one is setgid, where a program or a directory has the permissions of the group. This is probably used more with directories. In examples, one usually sees it shown with the write or wall command, which on FreeBSD is owned by user root and group tty. Again, if you test it by removing the sticky bit, with chmod 0555 or chmod g-s, you'll find that an unprivileged user won't be able to use the command. In this case, the octal value is 2 so you can put it back with
chmod +2000 /usr/bin/wall |
Once again, the +2000 puts in the sticky bit without changing other permissions. Otherwise you can use chmod 2555 /usr/bin/wall, or chmod g+s.
The best way to learn this is probably to set a test machine and with a root terminal session running, so you can fix whatever you break, remove the setuid or setgid bit and see what happens. It *will* break the program you test it on, so be ready to set the permissions back.
Another way setgid is used to share a directory. If setgid is, err, set, a file created by user A will be able to be edited by user B, if they are in the same group and that group has write permission to the directory.
Lastly, we come to the sticky bit. The classic example for this is /tmp. If you run ls -ld /tmp you'll see drwxrwxrwxt. The t at the end indicates that the sticky bit is set.
What this means is that even though it has 777 permissions (written in octal as 1777 for the sticky bit) if user A creates a file, user B can NOT delete or overwrite it. It provides a way to have a directory that everyone can use, without worrying about someone else deleting a file you worked on. To add a sticky bit without changing other existing permissions, one can use chmod +1000 /directoryname. The symbolic way is to use chmod o+t. To remove the sticky bit (again, do this on a testing machine), you can use chmod o-t. Or, as the default octal permission on a directory like /tmp 1777 run chmod 0777. Once the sticky bit is removed, any file you create in the directory can be removed by any user.
All three of these can be useful. I mainly wrote this as a reminder to myself. As mentioned, most systems and programs have the permissions most people want so I use these infrequently. Hopefully, the reader will also find this page useful.