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

List:       samba-technical
Subject:    RE: 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-19 10:01:00
Message-ID: C26565C47763B14CB12582D33062BE9A49BAE880 () G5W2732 ! americas ! hpqcorp ! net
[Download RAW message or body]

Is there really no developer responsible for design or coding for group mem=
bership 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 bein=
g taken seriously.

Regards,

Adam



From: Burgess, Adam
Sent: 16 September 2013 11:52
To: 'samba-technical@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 comm=
ent?

This is a design question  to begin with.  I can not find clear documentati=
on for Samba to explain if a the primary gid for the UNIX account is consid=
ered 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 no=
t (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 perm=
ission defined applied to it for the UNIX gid of the creating process (in U=
NIX context this is the primary GID).  Should this ACL be added or not if g=
roup membership via token does not include this group?

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

Regards,

Adam

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


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]