[Samba] SGID bit not obeyed in 4.3.9?

[Smith, Jarrod A]

> On May 18, 2016, at 4:08 PM, Rowland penny <rpenny at samba.org> wrote:
> 
> On 18/05/16 21:18, Smith, Jarrod A wrote:
>>> On May 18, 2016, at 2:38 PM, Rowland penny <rpenny at samba.org> wrote:
>>> 
>>> On 18/05/16 19:44, Smith, Jarrod A wrote:
>>>> We just upgraded to 4.3.9 (from 4.1.x) and are experiencing a few issues/differences around permissions on files written from Windows clients authenticated from winbind/AD.  One specific issue that we have is directories with permissions like:
>>>> 
>>>> drwxrws---+   9 myapp 9997  2048 May 16 17:38 .
>>> if you notice, there is a '+' at the end of 'drwxrws---', this means there are ACLs set, try running 'getfacl /path/to/the/directory'
>> Yes, we have acl_xattr enabled on this share.  There is a POSIX ACL on this directory and we added a default ACL that gives group 9997 rwx permissions and that part works (does get inherited on new objects created here).  But the user still wants group ownership on the file to be 9997, and I would like to understand what changed and why.
>> 
>>>> It's owned by user "myapp" and GID 9997 and as you can see we have the SGID bit set on this directory.  Prior to the upgrade, new files or directories created inside this directory would be owned by the 9997 GID, which is required for a particular workflow that involves uploading files from windows clients and then processing them with batch jobs on a Linux cluster.  After the upgrade, the behavior is broken - now the GID ownership goes to the default group membership coming from winbind/AD. Group 9997 does not exist in AD, and never has, which I suspect is why this was originally setup this way.
>>> What is '9997', where is it created ? does it exist in /etc/group ?
>>> 
>>> Does 'getent group 9997' produce any output ?
>>> 
>> This group doesn't exist on the Samba servers, which is why my "ls -l ." output in the first message did not resolve it.  This group is defined in /etc/group on the Linux cluster that mounts this underlying filesystem via GPFS.
>> 
>> As an aside, we are also getting complaints from other users that sound similar to an issue reported to the list on May 5 that secondary groups are not obeyed in 4.3.9. We have some shares defined to limit access to a particular (secondary) AD group and users are telling us that after the upgrade they can't map them any more.  Not sure if that is related to the issue I'm reporting here (maybe not) but It seems that groups are overall behaving differently for us on 4.3.9 vs. our previous 4.1.6.
>> 
>> Thanks
>> 
>> Jarrod
>> 
>> 
> 
> So, you want a group that doesn't exist on the Samba DC (it is a DC, isn't it ?) to have group ownership on something.
> Is '9997' the groups name or its GID number ?
> Have you considered creating the group in AD and then giving it a 'gidNumber' attribute containing '9997' (provided '9997' is a GID) or even creating the group at Unix level with the GID '9997' ?
> 
> As you say, something has changed, but it may just be that the 'something' is a 'fix' instead of a change.
> 

You'll get no argument from me that the way this was setup is inelegant.  So it's not a matter of what I want, but I guess I did expect that Samba would not override the SGID mechanism in the underlying filesystem.  That was not the case up through 4.1.6 at the least.

It's not a DC.  The Samba file servers (3, managed by CTDB) are joined to an AD domain, that I don't control. That's how Win clients authenticate to Samba.  The Linux cluster - where the group with GID 9997 comes from - has a local auth mechanism with UIDs/GIDs that don't match what comes from AD.  We typically deal with this mismatch by using POSIX ACLs (put both the AD and cluster UIDs/GIDs in the ACL).  It's ugly.  I wish I knew of a better way...synchronizing UIDs/GIDs between the two authentication services is very unlikely to happen.

So, that GID=9997 group doesn't exist in AD but I can ask for it to be added.  I added it to /etc/group on the Samba file servers and put myself in it, but that had no effect on the SGID behavior when writing through Samba. The SGID mechanism works fine from the Linux side.  It's just very surprising to me that this has stopped working for files/directories that Samba is adding to the filesystem.

The secondary groups I referred to, which appear to have stopped working, *do* exist in our AD.  Once I get this SGID issue resolved I will revisit that issue.

Thanks,

Jarrod