-
Leigh B. Stoller authored
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 be necessary). 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.
7e731fba