Bug #3691

setgroups() needs a sorted GID list for more than 16 groups

Added by Andrew Bartlett over 4 years ago. Updated about 2 years ago.

Status:ClosedStart date:2013-04-04
Priority:HighDue date:
Assignee:Ira Cooper% Done:

100%

Category:kernel
Target version:-
Difficulty:Bite-size Tags:

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.

testgroups-match-samba-acl.c Magnifier - acl setting binary (3.88 KB) Andrew Bartlett, 2013-04-04 02:02 AM

group2 - group file (672 Bytes) Andrew Bartlett, 2013-04-04 02:02 AM

passwd2 - passwd file (145 Bytes) Andrew Bartlett, 2013-04-04 02:02 AM

testgroups.c Magnifier - Demonstration of sorted GID values (works) (3.12 KB) Andrew Bartlett, 2013-04-09 06:06 AM

testgroups4.c Magnifier - Demonstration of reverse sorted GID values (fails on OpenIndiana, but not our NAS) (3.14 KB) Andrew Bartlett, 2013-04-09 06:06 AM

testgroups-match-samba-acl.c Magnifier - Demonstration of sorted GID values using ACLs (works) (4.05 KB) Andrew Bartlett, 2013-04-09 06:06 AM

testgroups-match-samba-acl4.c Magnifier - Demonstration of reverse sorted GID values (fails on both OpenIndiana and our NAS) (4.05 KB) Andrew Bartlett, 2013-04-09 06:06 AM


Related issues

Duplicated by illumos gate - Bug #3577: Problem handling groups with Winbind Closed 2013-02-19

History

#1 Updated by Andrew Bartlett over 4 years ago

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

#2 Updated by Marcel Telka over 4 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

#3 Updated by Björn Jacke over 4 years ago

also see my comment here in the initial bug report about the 16group issue: https://www.illumos.org/issues/3577#note-2

#4 Updated by Allen Belletti over 4 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!

#5 Updated by Ira Cooper over 4 years ago

I have a patch for this that I'm prepping for RTI.

#7 Updated by Ira Cooper over 4 years ago

  • % Done changed from 0 to 80

#8 Updated by Ira Cooper over 4 years ago

  • Category set to kernel
  • Difficulty changed from Medium to Bite-size
  • % Done changed from 80 to 90
  • Assignee set to Ira Cooper

Submitted for RTI.

#9 Updated by Rich Lowe over 4 years ago

  • % Done changed from 90 to 100
  • Status changed from New to Resolved
  • Tags deleted (needs-triage)

Resolved in b77dfcc8

#10 Updated by Gordon Ross about 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom