Meaning of setgid on an executable

Question

I get that setuid on a binary executable allows the process to get the effective uid of the binary owner. What I cannot understand is what if setuid bit is off but setgid bit is on for a particular executable. What happens in this case?

Example: Suppose we have following permissions

ls -l my_bin
r-xr-s--- root wheel my_bin

Now suppose user userA is a a member of group wheel. What happens when userA tries to run this program?

I am thinking that the effective user id of this process will become the same as uid for the user by the name wheel. It is a contrived example but I am confused by how group rights alter the effective uid or whether they have any impact on effective uid at all.

Answer 1

The setgid bit works the same as the setuid bit, but for the group ID. So the process will be run with an effective group ID of wheel. The effective (and real) user ID will still be that of whichever user started the program.

Your user's membership in that group doesn't matter one way or the other.

edit: example C program so you can play around with how it works. Not portable, but trivial to adopt for another system:

#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>

int main() {
    int ruid, euid, suid;
    int rgid, egid, sgid;

    if (0 != getresuid(&ruid, &euid, &suid)) {
        perror("getresuid");
        return 1;
    }
    if (0 != getresgid(&rgid, &egid, &sgid)) {
        perror("getresgid");
        return 1;
    }
    printf("ruid = %i, euid = %i, suid = %i\nrgid = %i, egid = %i, sgid = %i\n",
            ruid, euid, suid, rgid, egid, sgid);
    return 0;
}

Answer 2

The setgid bit can also be used on directories. If a directory has the setgid bit and is group writable, if a user (not the directory owner) with a different primary group writes a file in that directory and but has supplemental membership in the group that owns the directory, the new file gets the same group ownership as the directory. Not the primary group of the user writing the file. Very handy in some instances.

As an example we have two users, foo and bar. foo's primary group is also foo. bar's primary group is bar, but is a supplemental member of foo.

foo@valhalla:~$ id
uid=1002(foo) gid=1002(foo) groups=1002(foo)

bar@valhalla:~$ id
uid=1003(bar) gid=1003(bar) groups=1003(bar),1002(foo)

foo@valhalla:~$ grep foo /etc/group
foo:x:1002:bar
foo@valhalla:~$ grep bar /etc/group
foo:x:1002:bar
bar:x:1003:

I will create a directory /tmp/foodir and make it setgid and group writable.

foo@valhalla:~$ mkdir /tmp/foodir
foo@valhalla:~$ chmod g+ws /tmp/foodir
foo@valhalla:~$ ls -ld /tmp/foodir
drwxrwsr-x 2 foo foo 4096 Jun  6 19:30 /tmp/foodir

I will now touch a file in /tmp/foodir as the user bar.

bar@valhalla:~$ touch /tmp/foodir/barfile
bar@valhalla:~$ ls -l /tmp/foodir/barfile 
-rw-r--r-- 1 bar foo 0 Jun  6 19:32 /tmp/foodir/barfile

Notice the group ownership of /tmp/foodir/barfile is foo, not bar which is the user bar's primary group.

Now we try the other way around, but foo isn't a member of group bar.

bar@valhalla:~$ mkdir /tmp/bardir
bar@valhalla:~$ chmod g+ws /tmp/bardir
bar@valhalla:~$ ls -ld /tmp/bardir
drwxrwsr-x 2 bar bar 4096 Jun  6 19:34 /tmp/bardir

Look what happens when we try to touch a file as foo. It's what you should expect, a permission error.

foo@valhalla:~$ touch /tmp/bardir/foofile
touch: cannot touch '/tmp/bardir/foofile': Permission denied

And for one last step. We'll touch a file in /tmp (a not setgid directory that bar can write to) as bar.

 bar@valhalla:~$ ls -ld /tmp/barfile
-rw-r--r-- 1 bar bar 0 Jun  6 19:36 /tmp/barfile

The owner and group are both bar.