Bug#698102: eglibc: initgroups changes egid on kfreebsd
Michael, For now it sounds like there's no consensus that this is a bug in initgroups(3) in eglibc or setgroups(2) in kfreebsd. If you're aware of this leading to a bug in a specific Debian package (particularly if it is a bug with a security impact), please file a bug against that package. Jeff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
Unfortuantely, POSIX declined to specify setgroups() and initgroups() is not in any standard, so it's hard to say which behavior is right and which is wrong. It seems possible to argue any of the following: 1. The bug is in kFreeBSD's implementation of setgroups(), which must be fixed so that eglibc's initgroups() implementation works as expected. 2. The bug is in eglibc's implementation of initgroups(), which must be fixed so that it works properly with kFreeBSD's setgroups(). 3. Since both behaviors of setgroups() and initgroups() are seen "in the wild", programs that depend on the linux kernel behavior are broken and should be fixed as they become known. Personally I'm leaning towards 3 here, since these are buggy not only on debian/kFreeBSD but on real FreeBSD as well. Even POSIX point out that egid might be somewhere in supplementary groups http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgroups.html The getgroups() function shall fill in the array grouplist with the current supplementary group IDs of the calling process. It is implementation-defined whether getgroups() also returns the effective group ID in the grouplist array. Under FreeBSD kernel, the "egid" is groups[0], see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_prot.c IMO, there is no bug, the behaviour is implementation-defined. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
I've reworked the test program as follows: #include #include #include #define NGROUPS 32 void call() { gid_t groups[NGROUPS]; int ngroups = getgroups(NGROUPS, groups), i; printf("gid = %d egid = %d groups =", (int) getgid(), (int) getegid()); for(i =0; i< ngroups; i++) printf(" %d", (int) groups[i]); printf("\n"); } int main(void) { gid_t groups[] = {1, 2}; call(); setgroups(2, groups); call(); setgid(groups[0]); call(); setuid(groups[0]); call(); } now the dependence on glibc initgroups() is removed. On FreeBSD and kFreeBSD, the first group passed to setgroups becomes the effective group ID. On Linux, it does not: kfreebsd# gcc test.c && ./a.out gid = 0 egid = 0 groups = 0 gid = 0 egid = 1 groups = 1 2 gid = 1 egid = 1 groups = 1 2 gid = 1 egid = 1 groups = 1 2 freebsd9chroot# gcc test.c && ./a.out gid = 0 egid = 0 groups = 0 gid = 0 egid = 1 groups = 1 2 gid = 1 egid = 1 groups = 1 2 gid = 1 egid = 1 groups = 1 2 linux# gcc test.c sudo ./a.out gid = 0 egid = 0 groups = 0 gid = 0 egid = 0 groups = 1 2 gid = 1 egid = 1 groups = 1 2 gid = 1 egid = 1 groups = 1 2 The original program in freebsd9chroot (modified to use a different username): # ./a.out pw_name=jepler pw_uid=1001 pw_gid=1001 uid=0(root) gid=0(wheel) groups=0(wheel) uid=0(root) gid=0(wheel) egid=1001(jepler) groups=1001(jepler),5(operator) uid=0(root) gid=0(wheel) egid=1001(jepler) groups=1001(jepler),5(operator) uid=1001(jepler) gid=1001(jepler) groups=1001(jepler),5(operator) Unfortuantely, POSIX declined to specify setgroups() and initgroups() is not in any standard, so it's hard to say which behavior is right and which is wrong. It seems possible to argue any of the following: 1. The bug is in kFreeBSD's implementation of setgroups(), which must be fixed so that eglibc's initgroups() implementation works as expected. 2. The bug is in eglibc's implementation of initgroups(), which must be fixed so that it works properly with kFreeBSD's setgroups(). 3. Since both behaviors of setgroups() and initgroups() are seen "in the wild", programs that depend on the linux kernel behavior are broken and should be fixed as they become known. Personally I'm leaning towards 3 here, since these are buggy not only on debian/kFreeBSD but on real FreeBSD as well. Jeff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698102: eglibc: initgroups changes egid on kfreebsd
Hi Michael, I'm not sure I understand what the problem is. In normal situations setgid() is called first - that changes the process's real+effective group ID - then initgroups() may be used afterward to add any additional groups the user is a member of. If used in that order, your testcase seems to work as expected on GNU/kFreeBSD: > pw_name=steven > pw_uid=1000 > pw_gid=1000 > uid=0(root) gid=0(root) groups=0(root) then after setgid(1000) : > uid=0(root) gid=1000(steven) groups=0(root),1000(steven) then after initgroups(1000, 1000) : > uid=0(root) gid=1000(steven) > groups=0(root),1000(steven),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev) then after setuid(1000) : > uid=1000(steven) gid=1000(steven) > groups=1000(steven),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev) I'm not sure why you were seeing egid=27, but user 'michael' was already a member of that group. Only the superuser can use initgroups()... so I'm not sure this is a security problem? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org