Note : I filed an identical bug report against RHEL3 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113015). 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. This is a 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 = major. I'll file two attachments, with this testcase : $ smbclient \\\\host.bla.bla\\frans -U frans smb: \> ls smb: \> q The first attachment represents the valid results when the account is member of 31 groups; the second attachment represents the second permutation, with a group membership of 32 groups (yielding 'NT_STATUS_NETWORK_ACCESS_DENIED listing \*' in smbclient). 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.
Created attachment 349 [details] Correct behaviour, group membership = 31 (log level = 10)
Created attachment 350 [details] Bad behaviour, group membership = 32 (log level = 10)
Could this be related to bug #279 ? If so, would it prove beneficial to use the LDAP backend instead of /etc/group to determine file/directory resources ownership ?
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.
i just duplicated this as bug #1081 https://bugzilla.samba.org/show_bug.cgi?id=1081 i think, where 16 on Solaris is the magic number, versus your 32 on RHEL sorry see patch attached to that for my idea of what's wrong, anyway, whether samba dudes agree or not --buck
*** This bug has been marked as a duplicate of 1081 ***
database cleanup