samba - Nov 2016 - Clients can't write to group-writable files - plea for help

On Tue, Nov 15, 2016 at 11:42:45AM -0500, Josh Malone via samba
wrote:
> On 11/14/16 6:32 PM, Jeremy Allison via samba wrote:
> >On Mon, Nov 14, 2016 at 11:38:52AM -0500, Josh Malone via samba wrote:
> >>All,
> >>
> >>Apologies for basically bumping my own thread, but I'm
absolutely at
> >>my wits' end trying to figure out this access problem. I've
> >>replicated the issue with and without NFS being involved. On our
old
> >>4.0.25 server, users can write to files that they have group-based
> >>write permissions. On 4.5.x, 4.4.x, and 4.3.x that permission is
not
> >>being honored.
> >
> >
> >Look for an ACCESS_DENIED. Check the token of the smbd
> >issuing that error. We check the Windows ACL against
> >the token before allowing the write.
> 
> Thank you for that pointer. So, if I take this line for example:
> 
>   smbd_check_access_rights: file . requesting 0x40 returning 0x40
> (NT_STATUS_ACCESS_DENIED)
> [2016/11/14 12:49:21.540401, 10, pid=28398, effective(2310, 2049),
> real(2310, 0)] ../source3/smbd/open.c:179(smbd_check_access_rights)
> 
> I see that smbd #28398 is the offending process. I'm not sure what
> the "token" is that I'm looking for. Again - sorry for my
lack of
> familiarity with the internals here. I've *never* had issues like
> these with Samba before.
The token is the list of uids/gids (or SIDs in Windows terms)
that this smbd is using to represent the user right now.
> However, I see this bit:
> 
> 
>   canon_ace index 0. Type = allow SID = S-1-22-1-0 uid 0 (root)
> SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx
>   canon_ace index 1. Type = allow SID = S-1-22-2-0 gid 0 (root)
> SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x
>   canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER
> ace_flags = 0x0 perms r-x
Looks like a perm set of rwxr-xr-x on the file to me, with
owner and group of root.
> My interpretation of this is that samba things that the file GID is
> 0 and that group write is not allowed. This is not at all what the
> file permissions are though. Am I mis-reading this or is Samba
> getting permissions some other way. This is a purely Unix filesystem
> - there should be no NTFS ACLs.
smbd synthesises NT ACLs from the POSIX perms in order to do
the access checks. Then it checks the open request using the
current process token against the NT ACL to decide whether to
allow access.
> Also, the line:
> 
> [2016/11/14 12:49:21.964411,  5, pid=28398, effective(2310, 2049),
> real(2310, 0)]
> ../libcli/smb/smb2_signing.c:92(smb2_signing_sign_pdu)
> 
> How is the real different from the effective on a simple unix file?
These come from the current uid/gid of the process - constructed
here:

                        ", effective(%u, %u), real(%u, %u)",
                        (unsigned int)geteuid(), (unsigned int)getegid(),
                        (unsigned int)getuid(), (unsigned int)getgid());

Thay line tells you that pid 28398 is currently running with
an effective uid of2310, and an effective gid of 2049.

They are the values that will be used to check file access.

On 11/15/16 7:25 PM, Jeremy Allison wrote:
>
> The token is the list of uids/gids (or SIDs in Windows terms)
> that this smbd is using to represent the user right now.
Okay - that makes sense. Thank you.
>>
>>   canon_ace index 0. Type = allow SID = S-1-22-1-0 uid 0 (root)
>> SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx
>>   canon_ace index 1. Type = allow SID = S-1-22-2-0 gid 0 (root)
>> SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x
>>   canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER
>> ace_flags = 0x0 perms r-x
>
> Looks like a perm set of rwxr-xr-x on the file to me, with
> owner and group of root.
But the file is not root:root - it's owned by uid 12477 and group 9006. 
Why is Samba getting the wrong owner/group for this file?
>
> smbd synthesises NT ACLs from the POSIX perms in order to do
> the access checks. Then it checks the open request using the
> current process token against the NT ACL to decide whether to
> allow access.
>
>> Also, the line:
>>
>> [2016/11/14 12:49:21.964411,  5, pid=28398, effective(2310, 2049),
>> real(2310, 0)]
>> ../libcli/smb/smb2_signing.c:92(smb2_signing_sign_pdu)
>>
>> How is the real different from the effective on a simple unix file?
>
> These come from the current uid/gid of the process - constructed
> here:
>
>                         ", effective(%u, %u), real(%u, %u)",
>                         (unsigned int)geteuid(), (unsigned int)getegid(),
>                         (unsigned int)getuid(), (unsigned int)getgid());
>
> Thay line tells you that pid 28398 is currently running with
> an effective uid of2310, and an effective gid of 2049.
>
> They are the values that will be used to check file access.
Okay - so it's getting the right values for my user, but coming up with 
the wrong permissions on the file I'm trying to access. Any idea why?

I've been trying to debug this for days now - every build I make on Red 
Hat Enterprise 6 does this. However, running Samba under Ubuntu server 
behaves correctly in the same AD/NFS environment.

I've found another RHEL6 server here that's not showing the problem, so 
I'm going to try to diff the 2 boxes and see what's up.

-Josh

-- 
--------------------------------------------------------
        Joshua Malone       Systems Administrator
      (jmalone at nrao.edu)    NRAO Charlottesville
         434-296-0263           www.nrao.edu
	434-249-5699 (mobile)
--------------------------------------------------------

On 11/16/16 8:44 AM, Josh Malone via samba wrote:
>
> Okay - so it's getting the right values for my user, but coming up with
> the wrong permissions on the file I'm trying to access. Any idea why?
>
> I've been trying to debug this for days now - every build I make on Red
> Hat Enterprise 6 does this. However, running Samba under Ubuntu server
> behaves correctly in the same AD/NFS environment.
>
> I've found another RHEL6 server here that's not showing the
problem, so
> I'm going to try to diff the 2 boxes and see what's up.
>
> -Josh
>
I've tracked the problem down to some squirrely magic in username 
mapping. I don't understand it, but the other server had a username map 
script that just returns the same thing it was called with 99% of the 
time. If I use that script instead of my empty usermap.cfg file, things 
work properly. If i leave out the map entirely (no script, no file ) 
things fail as before.

What does a normal "everything matches on windows and unix" username
map
file need to look like?

Thanks again,

-Josh

-- 
--------------------------------------------------------
        Joshua Malone       Systems Administrator
      (jmalone at nrao.edu)    NRAO Charlottesville
         434-296-0263           www.nrao.edu
	434-249-5699 (mobile)
--------------------------------------------------------

On Wed, Nov 16, 2016 at 08:44:35AM -0500, Josh Malone via samba
wrote:
> On 11/15/16 7:25 PM, Jeremy Allison wrote:
> >
> >The token is the list of uids/gids (or SIDs in Windows terms)
> >that this smbd is using to represent the user right now.
> 
> Okay - that makes sense. Thank you.
> 
> >>
> >>  canon_ace index 0. Type = allow SID = S-1-22-1-0 uid 0 (root)
> >>SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx
> >>  canon_ace index 1. Type = allow SID = S-1-22-2-0 gid 0 (root)
> >>SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x
> >>  canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER
> >>ace_flags = 0x0 perms r-x
> >
> >Looks like a perm set of rwxr-xr-x on the file to me, with
> >owner and group of root.
> 
> But the file is not root:root - it's owned by uid 12477 and group
> 9006. Why is Samba getting the wrong owner/group for this file?
That is the core of your problem. What does the full debug
level 10 log say around this message ?