Who, where, what.

Linux file permissions is all about numbers: read permissions correspond to a "4", write permissions correspond to a "2" and execute permissions correspond to a "1".

When you sum the previous values, you'll get the corresponding "rwx"-scheme (incidentally this also happens to correspond to 3 bits - From 000 To 111).

Every file's property has 3 (visible) sets of permissions - the first set (first group of "rwx" preceded by a dash symbol) corresponds to the owner's file permissions, the second set of permissions indicates the group's permissions (second set of rwx) and the third set indicates everyone's permissions.

• In addition to the visible set of 3-bits, there's a fourth set of bits I'll hereby describe.

At this point, if you (still) don't know what I am talking about, please review the Standard POSIX filsesystem permissions, more specifically, please refer to the "Numeric Notation" at Wikipedia: http://en.wikipedia.org/wiki/Filesystem_permissions#Numeric_notation

The fourth scheme: setuid.

The setuid bit is another set of bits that is applied to file permissions.

Setuid is special set because it grants a Standard User the permission to execute a program (say /bin/ping).

Example - Have a look at the ping command permissions in the following screenshot:

-"rws" - "r-x" - "r-x" <- everyone.

You'll notice that ping has "r-x" permissions applied to "everyone" (ie. the third set of 3-bits aka as "other", already set to r-x).

• This doesn't mean it's a security risk, it simply means that every valid user logged-on to the host has the ability to run the ping command.

'Though, since ping deals with network adapters to send packets (which is a privileged operation), normally you'd expect for your average user not to have access to those specific network adapters features as such (or would you?).

So, in order to grant people the "privilege" to ping (without impacting the security of your system by giving them admin credentials), the designers of the POSIX permissions "compromised" by implementing the "suid" bit (shown as "s" in the above screenshot).

In other words, the suid bit allows your standard user(s) to "execute the command as if they were the owner of the ping command" (the command owner is root in this case). It's like having some guests at your place - one of them asks: "May I use your toilet, please?" You'd say: "Sure, you're welcome" (but the toilet is still yours!).

...Or setgid to files.

setgid works similarly to setuid, with the only difference that, rather than allowing you to execute a command as if you were the "owner" (such as ping), setgid grants "everyone" (more correctly, other) the permissions to operate a command as if they belonged to the "group".

(in the above example with the ping command, whoever may operate the ping command as if they belonged to the "root"-group).

Hope the above make sense.

 

man setuid.

In short, whenever you want to execute a command, but you want your command to be "Run As" if you were the Owner of the command (or Run as if you belonged to the Group launching the command), you may apply a setuid (User ID) or setgid (Group ID) to your file (respectively) as follows:

setuid: chmod 4xxx file.sh
setgid: chmod 2xxx file.sh

As you can see, to change your setuid or setgid (in both cases), you'd still use chmod.

For example, "sudo" is setuid by definition (and is owned by root).

Whenever you type "sudo" on your terminal, the binary command inherits root's permissions and capabilities.

 

"setuid" and "setgid" for Windows Users.

Similar in concept (not in the details 'though), on Windows you may:

SetUID -> RIGHT Click -> "Run as Administrator" (which generally is not the "owner" because on Windows the "Owner" is a more advanced concept than on LINUX).

OR

SerGID -> SHIFT+Right Click -> "Run as different User" to run as your custom User - especially useful on multi-domain and multi-forests environments).

SETUID and SETGID might get dangerous - For example, if you setuid a binary Owned by root (say vim), and a vulnerability that could create a stack overflow is discovered on vim, a malicious hax0r can stick his evil code into vim then "Run (his code) as" root.

So, to prevent "goulification of your system" [Cit. Fallout 3 - Three Dogs], make sure you fully understand the consequences of changing those bits (ie. "never use it").

 

Sticky Bits.

Sticky bits on Linux, in layman's terms, will prevent your users to delete files.

Say you have "some-log-file.log", Owned by a Group named "staff".

To prevent "some-log-file.log" deletion, you can set something known as a "Sticky Bit" directly on the file itself (or on the directory).

By assigning 1 to files and directories (still via the standard chmod command), as follows:

chmod 1755 [file.log or dir]

You will prevent the accidental removal of "file.log" or "dir" (this also includes all the files contained within the "dir" folder) .

 

Setuid & Setgid Security Checks.

To check which apps have been setuid-ed and setgid-ed, you can rely on checksecurity:

sudo apt-get install checksecurity
sudo checksecurity

Checksecurity:"does some very basic system security checks, such as looking for changes in which programs have setuid permissions[..]".

Now feel free to experiment and share your findings on the comments.

Other examples.

setuid=4755=rwsr-xr-x (command: chmod 4755 filename).

setuid+setgid=6775=rwsrwsr-x (command: chmod 6755 filename).

setgid=2775=rwxrwsr-x (command: chmod 2775 filename).