Description of problem: When a UNIX account is a member of more than 31 secondary groups, samba refuses to honour secondary groups membership, and denies access to all files and directories which are not owned by primary uid or gid. Version-Release number of selected component (if applicable): samba-3.0.0-14.3E How reproducible: Always Steps to Reproduce: 1. Create UNIX account with 31 secondary group memberships 2. Add user to additional group 3. Use e.g. smbclient to access a file or directory which is owned by one of the 32 groups, but different from the account's primary group. Actual results: Access is denied. Expected results: Access should be allowed, due to UNIX group membership. Additional info: This is a very unpleasant regression, compared to samba 2.x. As an interim 'solution', we now need to exclude accounts from groups (rendering their maximum group membership to 31 or lower), effectively denying them access to group-owned resources. As users are now unable to retrieve data which they previously could access under samba 2.x, I'm setting severity = high.
Created attachment 96802 [details] log level = 10, with 31 secondary groups $ smbclient \\\\host.bla.bla\\frans -U frans smb: \> ls smb: \> q
Created attachment 96803 [details] log level = 10, with 32 secondary groups ; result = NT_STATUS_NETWORK_ACCESS_DENIED $ smbclient \\\\host.bla.bla\\frans -U frans smb: \> ls NT_STATUS_NETWORK_ACCESS_DENIED listing \* smb: \> q
Please note I mention 31/32 secondary groups, while the logs reveal 32/33 supplementary groups : this is because each user belongs to primary gid 100 ('users'), but is again explicitly stated as a member of group 'users:x:100:' in /etc/group. (the rationale for this is to allow our Postfix mail server to use /etc/group to determine group membership when sending e-mails to departmental groups). As such, the summary of this bug report should perhaps be modified (31 -> 32).
Bug report also filed with Samba Bugzilla (https://bugzilla.samba.org/show_bug.cgi?id=945).
Additional information : test config 1: - Red Hat Linux 7.1, kernel2.4.9-31, samba-2.2.2-20011013 test config 2: - RHEL3, kernel-2.4.21-4.0.1.EL, samba-3.0.0-14.3E Both configs : - account 'xyz' is a member of approx. 35 groups ; - linux/limits.h : NGROUPS_MAX = 32 config 1 : 'groups xyz' reports first 32 groups ; config 2 : 'groups xyz' reports all 35 groups ; Test 1 : home uid = nobody, gid set to e.g. 35th group ; 1a:ssh to config1: access denied 1b:smbclient to config1: access denied 1c:ssh to config2: access denied 1d:smbclient to config2: access denied Test 2 : home uid = nobody, gid set to e.g. 10th group ; 2a:ssh to config1: access allowed 2b:smbclient to config1: access allowed 2c:ssh to config2: access allowed 2d:smbclient to config2: access denied (this concerns this bug report) Test 2d is IMO clearly a bug.
This is a 2.4 kernel limitation, with pervasice userland issues. I've been dealing with this for years now, and it effects numerous components, not just samba. http://www.ussg.iu.edu/hypermail/linux/kernel/0111.1/1716.html and http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.3/1432.html FC2 does not appear to have this problem IIRC, (though I haven't tested with our NIS setup), so it would be a shame to wait until RH 3.1 or 4.0 to see this fixed.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.