Bug #3691
closed
setgroups() needs a sorted GID list for more than 16 groups
100%
Description
I create two users and 20 groups. I put one user in 10 groups, the other in 20 groups (passwd/group files attached). I then run the attached C program to set ZFS acls, allowing those groups to access the files.
The GID values matter - this issue didn't reproduce on my first attempt with a base of 2000, but did when I exactly matched the failing values given by Samba's winbindd on the failing system. I was then able to reproduce the exact situation on OpenIndiana Build 151a7 Desktop DVD (32/64-bit x86).
I tried to have a single testing binary demonstrate the issue by becoming a normal user with a large number of grops, but I only see this when I use examine left-behind files (in test/) using su testuser2.
Steps to reproduce.
Attached are group2 and passwd2. Concatonate these onto /etc/passwd and /etc/group:
sudo sh -c 'cat passwd2 >>/etc/passwd '
sudo sh -c 'cat group2 >>/etc/group '
In particular, note that both users are in groups:
65548 65549 65550
/share is on a ZFS volume:
/ on rpool/ROOT/openindiana read/write/setuid/devices/dev=2c10002 on Thu Jan 1 10:00:00 1970
User with 20 groups (failure):
root@openindiana:/share# rm -rf test && ~abartlet/./testgroups-match-samba-acl 20 Got 20 groups 65536 65537 65538 65539 65540 65541 65542 65543 65544 65545 65546 65547 65548 65549 65550 65551 65552 65553 65554 65555 root@openindiana:/share# su testuser2 bash: /root/.bashrc: Permission denied bash-4.0$ ls -la test ls: cannot access test/65543: Permission denied ls: cannot access test/65549: Permission denied ls: cannot access test/65550: Permission denied ls: cannot access test/65544: Permission denied ls: cannot access test/65539: Permission denied ls: cannot access test/65540: Permission denied ls: cannot access test/65554: Permission denied ls: cannot access test/65547: Permission denied ls: cannot access test/65538: Permission denied ls: cannot access test/65545: Permission denied ls: cannot access test/65551: Permission denied ls: cannot access test/65548: Permission denied ls: cannot access test/65542: Permission denied ls: cannot access test/65546: Permission denied ls: cannot access test/65555: Permission denied ls: cannot access test/65536: Permission denied ls: cannot access test/65541: Permission denied total 8 drwxrwxr-x 22 root root 22 2013-04-04 12:11 . drwxr-xr-x 13 root root 13 2013-04-04 12:11 .. ??????????? ? ? ? ? ? 65536 drwx------+ 3 root root 3 2013-04-04 12:11 65537 ??????????? ? ? ? ? ? 65538 ??????????? ? ? ? ? ? 65539 ??????????? ? ? ? ? ? 65540 ??????????? ? ? ? ? ? 65541 ??????????? ? ? ? ? ? 65542 ??????????? ? ? ? ? ? 65543 ??????????? ? ? ? ? ? 65544 ??????????? ? ? ? ? ? 65545 ??????????? ? ? ? ? ? 65546 ??????????? ? ? ? ? ? 65547 ??????????? ? ? ? ? ? 65548 ??????????? ? ? ? ? ? 65549 ??????????? ? ? ? ? ? 65550 ??????????? ? ? ? ? ? 65551 drwx------+ 3 root root 3 2013-04-04 12:11 65552 drwx------+ 3 root root 3 2013-04-04 12:11 65553 ??????????? ? ? ? ? ? 65554 ??????????? ? ? ? ? ? 65555 bash-4.0$ id -G 65537 65552 65561 65560 65559 65558 65557 65556 65555 65554 65553 65551 65548 65549 65550 65567 65566 65565 65564 65563 65562
Notice how they are in 65548,65549,65550 but cannot access/see those folders?
User with less groups (success):
root@openindiana:/share# su testuser bash: /root/.bashrc: Permission denied bash-4.0$ ls -la test ls: cannot access test/65543: Permission denied ls: cannot access test/65544: Permission denied ls: cannot access test/65539: Permission denied ls: cannot access test/65540: Permission denied ls: cannot access test/65553: Permission denied ls: cannot access test/65554: Permission denied ls: cannot access test/65547: Permission denied ls: cannot access test/65538: Permission denied ls: cannot access test/65545: Permission denied ls: cannot access test/65551: Permission denied ls: cannot access test/65542: Permission denied ls: cannot access test/65546: Permission denied ls: cannot access test/65555: Permission denied ls: cannot access test/65552: Permission denied ls: cannot access test/65536: Permission denied ls: cannot access test/65541: Permission denied total 9 drwxrwxr-x 22 root root 22 2013-04-04 12:11 . drwxr-xr-x 13 root root 13 2013-04-04 12:11 .. ??????????? ? ? ? ? ? 65536 drwx------+ 3 root root 3 2013-04-04 12:11 65537 ??????????? ? ? ? ? ? 65538 ??????????? ? ? ? ? ? 65539 ??????????? ? ? ? ? ? 65540 ??????????? ? ? ? ? ? 65541 ??????????? ? ? ? ? ? 65542 ??????????? ? ? ? ? ? 65543 ??????????? ? ? ? ? ? 65544 ??????????? ? ? ? ? ? 65545 ??????????? ? ? ? ? ? 65546 ??????????? ? ? ? ? ? 65547 drwx------+ 3 root root 3 2013-04-04 12:11 65548 drwx------+ 3 root root 3 2013-04-04 12:11 65549 drwx------+ 3 root root 3 2013-04-04 12:11 65550 ??????????? ? ? ? ? ? 65551 ??????????? ? ? ? ? ? 65552 ??????????? ? ? ? ? ? 65553 ??????????? ? ? ? ? ? 65554 ??????????? ? ? ? ? ? 65555 bash-4.0$ id -G 65537 65548 65549 65550 65567 65566 65565 65564 65563 65562
This user can get to 65548,65549,65550 but is correctly denied access to other
folders that are not in it's shorter GID list.
The GID lists are as provided by idmap and winbindd on the NAS, so are not
nicely consecutive.
Sadly I still can't reproduce this without going back to the shell and using
su, as a self-contained testing binary would be much easier to work with.
Files
Related issues
Updated by Andrew Bartlett about 10 years ago
- File testgroups.c testgroups.c added
- File testgroups4.c testgroups4.c added
- File testgroups-match-samba-acl.c testgroups-match-samba-acl.c added
- File testgroups-match-samba-acl4.c testgroups-match-samba-acl4.c added
I've been able to the need for /etc/passwd and /etc/group values to reproduce this issue, and produced a self-contained binary.
I think the issue is that setgroups() needs a sorted GID list for more than 16 groups. I note that getgroups() on linux returns a sorted list, while getgroups() on OpenIndiana returns the original list, as is.
Presumably something is doing a bisection search on lists > 16 long.
Demonstration of the failure:
root@openindiana:/share# rm -rf test && ~abartlet/testgroups-match-samba-acl4 17 100000
Got 17 groups
100016 100015 100014 100013 100012 100011 100010 100009 100008 100007 100006 100005 100004 100003 100002 100001 100000
testgroups-match-samba-acl4: failed to stat test/100016/test: Permission denied
root@openindiana:/share# rm -rf test && ~abartlet/testgroups-match-samba-acl4 16 100000
And success for 16 groups:
Got 16 groups
100015 100014 100013 100012 100011 100010 100009 100008 100007 100006 100005 100004 100003 100002 100001 100000
And success regardless for sorted GID values:
root@openindiana:/share# rm -rf test && ~abartlet/testgroups-match-samba-acl 17 100000
Got 17 groups
100000 100001 100002 100003 100004 100005 100006 100007 100008 100009 100010 100011 100012 100013 100014 100015 100016
root@openindiana:/share# rm -rf test && ~abartlet/testgroups-match-samba-acl 16 100000
Got 16 groups
100000 100001 100002 100003 100004 100005 100006 100007 100008 100009 100010 100011 100012 100013 100014 100015
Updated by Marcel Telka about 10 years ago
- Subject changed from SOME Directories with ZFS ACLs only visable if user is in less than 16 (or so) groups to setgroups() needs a sorted GID list for more than 16 groups
Updated by Björn Jacke about 10 years ago
also see my comment here in the initial bug report about the 16group issue: https://www.illumos.org/issues/3577#note-2
Updated by Allen Belletti almost 10 years ago
Wanted to add my comments as the reporter of https://www.illumos.org/issues/3577. The patch that Andrew Bartlett produced for Samba does work around this problem. That seems to provide further confirmation that ordering the groups avoids the Illumos problem.
It would be very helpful to see this bug prioritized. Oracle Solaris works very poorly on some generic x86 hardware, not to mention being entirely closed. Having Illumos-based distros work well with Samba is important to making it the clear choice in file server software for both NFS and CIFS. Thanks!
Updated by Ira Cooper almost 10 years ago
I have a patch for this that I'm prepping for RTI.
Updated by Ira Cooper almost 10 years ago
Patch is at: http://cr.illumos.org/~webrev/icooper/3691/
Updated by Ira Cooper almost 10 years ago
- Category set to kernel
- Assignee set to Ira Cooper
- % Done changed from 80 to 90
- Difficulty changed from Medium to Bite-size
Submitted for RTI.
Updated by Rich Lowe almost 10 years ago
- Status changed from New to Resolved
- % Done changed from 90 to 100
- Tags deleted (
needs-triage)
Resolved in b77dfcc8
Updated by