If you’re new to Linux administration, you’ve probably already started learning about file permissions. If I said “drwxrwxr-x,” you’d know what that meant. It’s simple: A directory with owner and group read, write, execute permissions, but only read and execute permissions for everyone else.
That’s not the be-all, end all for permissions. There are actually three more permissions, one of which I’m going to teach you about right now. Said permission is called SUID, which stands for Set owner User ID. This is a special permission that applies to scripts or applications. If the SUID bit is set, when the command is run, it’s effective UID becomes that of the owner of the file, instead of the user running it.
SEE: Kubernetes security guide (free PDF) (TechRepublic)
This is used to provide temporary elevated permissions during execution. For example, if the file being executed was owned by root and has the SUID bit set, no matter who is running the script or application, the permissions would always (temporarily) equal those of root.
One very easy-to-understand example of this is when a user wants to change their password and they issue the sudo passwd command. If the SUID bit wasn’t set on passwd, the command would be run without elevated privileges, and wouldn’t be able to write to the necessary files to change the password–hence the SUID bit.
If you create a script (owned by the root user) that needs the SUID bit set, you’d do so like:
sudo chmod u+s filename
Where filename is the name of the script or application. Once the SUID bit is set, anytime that application is executed, it will be executed with temporarily elevated privileges.
And that’s the gist of the SUID permission bit. It sounds more complicated than it really is. Although you might not use it every day, you’ll be glad you know it, when you run into a situation where it’s clearly necessary.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.