Bug#698102: eglibc: initgroups changes egid on kfreebsd

2013-01-29 Thread Jeff Epler
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

2013-01-28 Thread Petr Salinger

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

2013-01-27 Thread Jeff Epler
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

2013-01-27 Thread Steven Chamberlain
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