unanticipated breakage. If that happens, just need to back out the
changes under the "suexec-stuff" tag. However, the better solution will
probably be to fix the PHP scripts that break by adding the proper
groups in the call to suexec (in the web page, see below) or by fixing
the backend Perl script that breaks.
This fix is primarily to address the problem of some users being in more
groups (cause of subgroups) then the max number of groups allowed
(NGROUPS). The groups that really mattered (say, for creating an
experiment in a subgroup) could be left out cause they were at the end
of the list.
* suexec.c: Change how groups are handled. Instead of taking a single
gid argument (the gid to setgid as), now takes a comma separated list
of groups. Further, instead of doing a setgroups to the user's entire
group list as specified in the groups file (getgroups), setgroups to
just the groups listed on the command line, plus the user's primary
group from the password file (this is to prevent potential breakage
with accessing files from the users homedir, although might not really
This change is somewhat rational in the sense that in our case, suexec
is not being used to run arbitrary user code (CGIs), but only to run
specific scripts that we say should be run. The environment for
running those scripts can be more tightly controlled then it would
otherwise need to be if running some random CGI the user has in his
public html directory.
* www: Change the gid argument to SUEXEC() in a number of scripts so
that the project and subgroup are explicitly given to suexec, as
described above. For example, in beginexp:
SUEXEC(gid, "$pid,$unix_gid", ....);
Aside: note that project names (pid) are always one to one with their
unix group name, but subgroup names are not, and *always* have to be
looked up in the DB, hence the "unix_gid" argument.
Script breakage should require nothing more then adding the proper
group to the list as above.