samba - Sep 2013 - primary GID based access for user in 16 supplementary groups

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

Hiya Adam,

We too have had no end of problems with this sort of issue using Samba on
Solaris (11 in our case) running against AD and using (predominantly)
"Windows 7" clients.

Someone with more knowledge of the Samba internals can probably answer your
questions about what is the correct behaviour, and why this is happening.
However if you're like me, it's more urgent actually to have something
working than to know the precise details of implementation of some rather
nasty protocols ...

So - my $0.02, in case it's of any use.

1. For whatever reason, Samba does not play nicely when the GID of an object
does not match the account's primary GID.  One easy way (we've found
anyway
- YMMV) to demonstrate this is to locate any "$RECYCLE.BIN" directory
for a
user, change the GID to that of another group of which the user is a member,
then open the desktop "Recycle Bin" - you'll get a whinge about
"The recycle
bin on \\server\path\to\$RECYCLE.BIN is corrupted.  Do you want to empty the
Recycle Bin for this drive?" (or words to that effect).
2. Things work much more smoothly when the AD group membership for the user
includes the primary GID (and that's set as the primary group name in the
Unix attributes for the account).  It's not a cure for all ills, but it did
clear up a number of similar problems we had.
3. That, as you pointed out, may well break the Solaris internal limit of 16
groups.  However, is that really a problem for you?  More than 16 will break
NFSv3, but if you're not using NFSv3 then the worst that will happen is
you'll get whinged at at boot time and that's it.  Depending on your
version
of Solaris, there is an internal hard-coded kernel limit; as of OpenSolaris
"snv_129" it was increased from 32 (the limit you may well have) to
1024,
but if you're not over the limit (without including the primary GID) at 16
then 32 will easily be sufficient for you anyway.  We run with "set
ngroups_max = 1024" in our "/etc/system" (not that we need that
many, but
...) and things generally troll along smoothly as a result.  Oh, depending
(again) on which version you're running - if you've patched your Solaris
systems to a stage where they use Grub, don't forget the obligatory
"bootadm
update-archive", but I'm sure you know that already :-).
4. You've not gone into details of when (or even if) you might need to use
different GIDs on directories (or files, for that matter), though you did
point out that anything created will be created with the primary GID anyway.
Again, I'm sure you're aware of this, but you might find setting the
SGID
bit on folders to be useful to force different group ownership of anything
created in that directory.  If, that is, you need to be able to create new
filesystem objects with a group ownership of anything other than the primary
GID ...
5. Are you *absolutely* sure that your idmap back-ends are doing what you
thought?  It may be worthwhile running "wbinfo -U <UID>" and
checking the
SID for that UID against AD ("whoami /all |more" in a CMD window is
very
useful in this context ...); then "wbinfo -S <SID>" and
confirming that it
comes back to the correct UID.  We've also had some very odd behaviour where
it looks as though everything is correct, but the UID is actually being
mapped to a transient SID from an allocating back-end.  It maps to and fro
correctly, and Samba seems able (in our case) correctly to identify the user
(presumably from the Kerberos tickets) when a connection is established, and
so the correct UID is extracted from AD.  However since that UID then maps
to a transient SID when looked up (rather than the real SID which it should
match), you will get all sorts of bizarre permissions behaviour.  Same UID,
different SID, never the 'twain shall meet ...

Hopefully at least some of that may prove useful!

Cheers,

Tris Mabbs.

-----Original Message-----
From: Burgess, Adam [mailto:adam.burgess at hp.com] 
Sent: 05 September 2013 17:02
To: samba at lists.samba.org
Subject: [Samba] primary GID based access for user in 16 supplementary
groups

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