Passing arg -1 on mips64 to setregid causes failures. OK, -1 is a flag value for certain setuid and setgid system calls. The 32 bit value in uid_t and gid_t is not sign extended by glibc when passed to the kernel, but the kernel does sign extend in it's comparison check rgid != (gid_t)-1. This may be broken on all mips64 versions of glibc.
I have attached mips64 versions of certain files, as an example of how this might be fixed. (A real glibc developer would likely do it differently.)
Created attachment 1747 [details] setregid.c
Created attachment 1748 [details] setresgid.c
Created attachment 1749 [details] setresuid.c
Created attachment 1750 [details] setreuid.c
Created attachment 1751 [details] README
These files would go in the directory: glibc-2.5/ports/sysdeps/unix/sysv/linux/mips/mips64 LTP tests with this setegid pass setgid pass setregid pass setresgid pass setresuid pass setreuid pass setsid pass setuid pass
Created attachment 1753 [details] gid.c Run gid.c as root on mips64 to see failure.
I identified that there was a kernel bug with potential security implications involved in <http://lkml.org/lkml/2007/6/4/376> (4 June 2007). There were a few replies concluding that the kernel should indeed be converting the syscall arguments to the correct types (properly extended) before the main C syscall implementations were called, but no actual fix. It now appears someone else has rediscovered that there is, indeed, a security issue here and managed to get more action, and it's fixed in 2.6.29-rc2. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0029 So, no glibc bug here, but a kernel security bug that should be fixed in the latest kernel, more than a year and a half after I first identified the security issues in public.