OK, something is not quite right here. On my unmodified zope, it is properly 'sandboxed'. Perhaps it is the use of the explicit '-u nobody'? I don't do that on my system, which causes Zope to run as nobody implicitly.
(When started as root, unless told otherwise, zope will switch to nobody).
Try running without the 'u nobody switch, and see what happens. Just out of curiousity.
No difference. I think the point is that Zope does not make any initgroups(3) calls; this will be a problem if the particular system needs it. I have two such systems: Linux 2.2.16 + glibc-2.1.2 NetBSD 1.4 Having reviewed the kernel and libc sources in both cases, I am convinced that set*gid and {init,set,get}groups operate totally independently. At minimum, initgroups is used by login/su to set the primary gid found in /etc/passwd, plus any additional gids associated with the uid in /etc/group, as supplemental gids. Thus, even if there are no supplemental gids in /etc/group, you still have the primary gid in the kernel's list of supplementals. So the primary gid occurs initially in 3 places: the real and effective gids, and one of the supplemental gids. You must get all 3; setgid for real and eff, initgroups for sup. (Additionally in linux you have the `saved' gid and the fsgid, but setgid will modify them.) Under this hypothesis, my question is how could _your_ system work? Why is it that you don't have the original primary gid lingering in the supplemental list?