Primary GID based access when this GID is NOT part of resolved Windows security token

[Burgess, Adam]

Is there really no developer responsible for design or coding for group membership evaluation, and/or the code for determining accessibility to files/directories?

I believe I have raised an important issue here but it seems it is not being taken seriously.

Regards,

Adam



From: Burgess, Adam
Sent: 16 September 2013 11:52
To: 'samba-technical at lists.samba.org'
Subject: RE: Primary GID based access when this GID is NOT part of resolved Windows security token

Is there anyone who is responsible for group membership design able to comment?

This is a design question  to begin with.  I can not find clear documentation for Samba to explain if a the primary gid for the UNIX account is considered to be a group the user is a member of or not.

Further to this question is how to handle the resulting problem if it is not (the inconsistency of directory access, etc).

Also it raises the question of ACL inheritance.  If there is POSIX ACL gid default on a directory then any file created within it should have the permission defined applied to it for the UNIX gid of the creating process (in UNIX context this is the primary GID).  Should this ACL be added or not if group membership via token does not include this group?

Without answers to these questions it is not possible to plan an approach or to know when we can raises issues as bugs.

Regards,

Adam

From: Burgess, Adam
Sent: 09 September 2013 16:45
To: 'samba-technical at lists.samba.org'
Subject: Primary GID based access when this GID is NOT part of resolved Windows security token


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 (when this group is not one that would resolve as membership for the user account via the user's Windows security token).  Windows 7 client refuses access to a directory that should be accessible based on UNIX PGID for the UNIX user account's process context.

Debug of access via Windows clients shows subtle differences in the access_mask for the open requests but generally the check open rights functions return NT_STATUS_ACCESS_DENIED in all cases.  In the case of Win20003/XP this status reply is ignored and access is still attempted by the client.  With Windows 7 no access can be gained at all.

The following are relevant snips from level 10 debug for various client accesses to a dir owned by root:PGID (mode 750).  All clients showing as denied, but do show as status ok if read-execute is added for "other" or if group owner is a supplementary group.

smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x81 returning 0x1 (NT_STATUS_ACCESS_DENIED)
smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x20089 returning 0x20009 (NT_STATUS_ACCESS_DENIED)
smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x100001 returning 0x100001 (NT_STATUS_ACCESS_DENIED)
smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x100080 returning 0x100000 (NT_STATUS_ACCESS_DENIED)

Note that the Windows access failure occurs only for directory access and not for regular files!

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.


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 (syssetgroups PANIC etc).

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. I can see 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? Should the Windows client be ignoring the ACCESS_DENIED replies?  How can we resolve this problem for Windows 7 client access to UNIX PGID access based resources?

Regards,

Adam