[prev in list] [next in list] [prev in thread] [next in thread] 

List:       samba-technical
Subject:    Primary GID based access when this GID is NOT part of resolved Windows security token
From:       "Burgess, Adam" <adam.burgess () hp ! com>
Date:       2013-09-09 15:44:54
Message-ID: C26565C47763B14CB12582D33062BE9A49BAC3A4 () G5W2732 ! americas ! hpqcorp ! net
[Download RAW message or body]


We observe a difference between a Windows 7 client and Windows 2003/XP clie=
nt when accessing directories that should be accessible via the UNIX accoun=
ts primary group GID (when this group is not one that would resolve as memb=
ership for the user account via the user's Windows security token).  Window=
s 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 re=
turn 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 acc=
esses to a dir owned by root:PGID (mode 750).  All clients showing as denie=
d, but do show as status ok if read-execute is added for "other" or if grou=
p owner is a supplementary group.

smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x81 returning 0x=
1 (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 returnin=
g 0x100001 (NT_STATUS_ACCESS_DENIED)
smbd_check_open_rights: file PGIDACCESSONLYDIR requesting 0x100080 returnin=
g 0x100000 (NT_STATUS_ACCESS_DENIED)

Note that the Windows access failure occurs only for directory access and n=
ot for regular files!

Ignoring for now why the two different client behaviours (either some subtl=
e 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 win=
bindd IDMAP lookup to simple LDAP backend.


If we add the AD user account as a member of the PGID mapped AD group accou=
nt as a workaround, then this would consume a supplementary group slot in t=
he 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 fi=
les that might be created would be created with the user accounts PGID as i=
ts 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 wo=
uld think that the Windows token SIDs should be combined with the UNIX cont=
ext 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 constraine=
d 16 supplementary groups and to use PGID at all for resource control).  PG=
ID based resource control is required on Solaris when using a supplementary=
 group membership would not work due to the number of members total name st=
ring 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
[prev in list] [next in list] [prev in thread] [next in thread]