There is a check on correctness of the argument for setregid in posixmodule.c:

	if (!PyArg_ParseTuple(args, "ll", &rgid_arg, &egid_arg))
		return NULL;
	rgid = rgid_arg;
	egid = egid_arg;
	if (egid != egid_arg || rgid != rgid_arg) {
		PyErr_SetString(PyExc_OverflowError, "group id too big");
		return NULL;
	}

However, the egid_t(egid) is unsigned 32-bit, while egid_arg is signed 64-bit, so after this comparison the result "overflows".

I reproduced this bug on OSX 10.6:

>>> os.setregid(-1,-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: group id too big

Since -1 has special meaning as an argument to POSIX setregid(rgid, egid),

"""
If rgid is -1, the real group ID shall not be changed; if egid is -1, the effective group ID shall not be changed.
"""

I think passing -1 to os. setregid() should be supported.

Meanwhile the following work-around works for me on OSX, but may not work on other platforms:

>>> os.setregid(2**32-1,2**32-1)

Question:  If we allow -1 to be passed to os.setregid as (gid_t)-1, what should passing 2**32-1 mean? Two possibilities are: treat it same way as -1 or raise a "gid is to big" error.

fixed in trunk in r78546 & backported to 2.6 and 3.1.

Apparently there is a side effect on OS X 10.6 of setting to -1.  See Issue8045.