Set-uid root program that runs a program as the user "restrict"

Question

I've written a very short program that is intended to run the program specified in its arguments (argv) as the user named "restrict" (which exists). I want to make sure that there are no subtle bugs in the program, and that the program is as simple as possible.

• Is this program doing what I intend?
• Can someone use this program to do anything malicious? Assume that anything running as the user "restrict" is not able to do anything malicious, but anything running as the user "root" obviously can.
• Can this code be simplified, or (assuming the code is correct) can this code's correctness be made more obvious?

The code (compiled with gcc --std=c11):

#include <unistd.h>
int main (int argc, char **argv) {
    setuid(0); // Switch user to root.
    char *start[] = {
        "/usr/bin/sudo", "-u", "restrict", // Switch user to "restrict".
        "--" // End arguments.
    };
    int start_len = (sizeof start) / (sizeof start[0]);
    char *args[start_len+argc];
    char *env[] = {NULL}; // Delete all environment variables.
    int i;
    for (i = 0; i < start_len; ++i)
        args[i] = start[i];
    // Note that argv is null-terminated, so we can go past the end by one.
    // Conveniently, we also want to discard the first argument, so just loop
    // over the arguments as usual, but with an offset of one.
    for (i = 0; i < argc; ++i)
        args[start_len+i] = argv[i+1];
    execve(args[0], args, env);
}

The final binary will be owned by root, and will have the set-uid bit set, and will be executable by users in a particular group.

The ultimate goal is to allow users in a particular group to run any executable as the user "restrict".

Alternatively, is there a better way to accomplish this goal?

---

See Set-uid root program that runs a program as the user “restrict” (follow-up) for the next iteration of this code.

Answer 1

• Stay away from variable length arrays. First, they are optional in C11 (in C99 they were mandatory). Second, there is no way to detect allocation failure. A malicious user may invoke the program with a command line long enough to cause stack overflow.

• Why sudo? You are root already, so you may set the user and group ID directly.