[Samba] primary GID based access for user in 16 supplementary groups

[Burgess, Adam]

We observe a difference between a Windows 7 client and Windows 2003/XP client when accessing directories that should be accessible via the UNIX accounts primary group GID.  Windows client refuses access.

Ignoring for now why the two different client behaviours (either some subtle difference in the requests or the way the Samba reply is dealt with) the question is what should be the correct behaviour?

We are running Samba 3.6.6 on Solaris with 16 limit on supplementary group, using ADS security, Kerberos PAC based group membership resolution via winbindd IDMAP lookup to simple LDAP backend.

The SIDs in the PAC which resolve to valid GIDs are just the supplementary groups that would be expected for the UNIX name services resolution for the user account.  The primary GID does resolve to a valid AD group SID too but this group does not contain the AD user account as a member and so is not present in the Kerberos PAC of course.

In this case the smbd establishes the UNIX token context with correct UID/GID (primary) and the correct list of supplementary groups.  However when checking the open rights for a directory with ACLs that allow only the primary GID read/execute access to a directory for example the result is ACCESS DENIED.

For example debug level 10 log line:


[2013/08/30 13:38:45.318680, 10, pid=22761] smbd/open.c:139(smbd_check_open_rights)

  smbd_check_open_rights: file pgidaccessonlydir requesting 0x81 returning 0x1 (NT_STATUS_ACCESS_DENIED)

This prevents access from a Windows 7 client.

If we add the AD user account as a member of the PGID mapped AD group account as a workaround, then this would consume a supplementary group slot in the smbd process context which would break any access for accounts that are already in 16 supplementary groups.

Also it should be noted that once any access is given to a directory any files that might be created would be created with the user accounts PGID as its group owner.  This makes it even more bizarre that this group would not be considered as part of the membership when using winbind idmapping.  I would think that the Windows token SIDs should be combined with the UNIX context PGID's resolved SID for the expected behaviour from a UNIX perspective, but from an AD/Windows perspective it makes more sense that only PAC SIDs are used (but this creates an inability to use the already constrained 16 supplementary groups and to use PGID at all for resource control).  PGID based resource control is required on Solaris when using a supplementary group membership would not work due to the number of members total name string length would blow the NSS buf limit for group membership list (eg 8K).

What is the behaviour intended to be - implicit membership to UNIX PGID or not?  How can we resolve this problem for Windows 7 client access to UNIX PGID access based resources?

Cheers,

Adam