Meaning of setgid on an executable

setgid

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.

Best Answer

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;
}

Related Solutions

Group memberships and setuid/setgid processes

The problem is that setuid and setgid are not sufficient to give your process all the credentials it needs. The authorizations of a process depend on

its UID
its GID
its supplementary groups
its capabilities.

See man 7 credentials to get a more detailed overview. So, in your case, the problem is that you correctly set the UID and GID, but you don't set the supplementary groups of the process. And group bar has GID 54, no 73 so it is not recognized as a group your process is in.

You should do

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <grp.h>

int main (void) {
    gid_t supplementary_groups[] = {54};

    setgroups(1, supplementary_groups);
    setgid(73);
    setuid(73);
    int fd = open("/test.txt", O_RDONLY);
    fprintf(stderr,"%d\n", fd);
    return 0;
}

Debian – Unset setgid bit with chmod numeric mode

I've found it! This info is missing from the man page but is in the Coreutils manual online. To wit:

On most systems, if a directory’s set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. On a few systems, a directory’s set-user-ID bit has a similar effect on the ownership of new subfiles and the set-user-ID bits of new subdirectories. These mechanisms let users share files more easily, by lessening the need to use chmod or chown to share new files.

These convenience mechanisms rely on the set-user-ID and set-group-ID bits of directories. If commands like chmod and mkdir routinely cleared these bits on directories, the mechanisms would be less convenient and it would be harder to share files. Therefore, a command like chmod does not affect the set-user-ID or set-group-ID bits of a directory unless the user specifically mentions them in a symbolic mode, or uses an operator numeric mode such as ‘=755’, or sets them in a numeric mode, or clears them in a numeric mode that has five or more octal digits.

Reference: https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Best Answer

Related Solutions

Group memberships and setuid/setgid processes

Debian – Unset setgid bit with chmod numeric mode

Related Question