We're having a problem with multiple group membership. (I thought it was working at one point, but at the moment it appears not to be.)
Our appliance's privilege strategy involves all higher-privilege users automatically being a member of all lower-privilege groups. To wit (simplified): > cat /etc/passwd root:x:0:0:root:/:/bin/sh one:x:500:503::/tmp/users/one:/bin/sh two:x:503:502::/tmp/users/two:/bin/sh three:x:502:501::/tmp/users/three:/bin/sh four:x:501:500::/tmp/users/four:/bin/sh > cat /etc/group root:x:0:root,one,two,three a:x:503:one,two,three b:x:502:one,two,three c:x:501:one,two,three d:x:500:one,two,three,four > If you are "root", say, and switch to "one", given the above database you should automatically be a member of the root,a,b,c,d groups. But we're not: > id -a uid=0(root) gid=0(root) > su -s /bin/sh - gss > id -a uid=500(one) gid=503(a) > This is Busybox 1.14.2, and id 7.4 from coreutils. I _expect_ output like: uid=500(one) gid=503(a) groups=root(0),a(503),b(502),c(501),d(500) Even if you login (Busybox) it's the same. I was looking at initgroups() in pwd_grp.c, and it looked fairly plausible, except that it looked to me like getgrouplist_internal() was _excluding_ group lines that matched your target (primary?) group (OK) or one that had your name in it (not OK?). Am I way off base here? This _is_ supposed to work, innit? The appliance generally has g=u permissions, which relies upon the group lists being there. It's having trouble, a high-privileged (a) user is unable to manipulate 0664 root/root files, etc. I could have sworn this worked when we released the first appliance, several years ago, but recently selected admin tasks are failing on new pending releases. -- Jim _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
