Bug 945 - Access denied to accounts with secondary UNIX groups membership > 31
Summary: Access denied to accounts with secondary UNIX groups membership > 31
Status: RESOLVED DUPLICATE of bug 1081
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.0
Hardware: All All
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact:
Depends on:
Reported: 2004-01-07 06:40 UTC by Didier Moens
Modified: 2005-11-14 09:29 UTC (History)
0 users

See Also:

Correct behaviour, group membership = 31 (log level = 10) (72.95 KB, text/plain)
2004-01-07 06:41 UTC, Didier Moens
no flags Details
Bad behaviour, group membership = 32 (log level = 10) (67.33 KB, text/plain)
2004-01-07 06:42 UTC, Didier Moens
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Didier Moens 2004-01-07 06:40:09 UTC
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
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.
Comment 1 Didier Moens 2004-01-07 06:41:47 UTC
Created attachment 349 [details]
Correct behaviour, group membership = 31 (log level = 10)
Comment 2 Didier Moens 2004-01-07 06:42:31 UTC
Created attachment 350 [details]
Bad behaviour, group membership = 32 (log level = 10)
Comment 3 Didier Moens 2004-01-07 06:45:02 UTC
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 ?
Comment 4 Didier Moens 2004-01-07 07:43:16 UTC
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.

Comment 5 Buck Huppmann 2004-02-15 20:10:19 UTC
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

Comment 6 Gerald (Jerry) Carter (dead mail address) 2004-03-15 14:12:59 UTC

*** This bug has been marked as a duplicate of 1081 ***
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:29:58 UTC
database cleanup