Note : I filed an identical bug report against RHEL3
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
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
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
i think, where 16 on Solaris is the magic number, versus your 32 on RHEL
see patch attached to that for my idea of what's wrong, anyway, whether
samba dudes agree or not
*** This bug has been marked as a duplicate of 1081 ***