[Bugs] [Bug 1797099] After upgrade from gluster 7.0 to 7.2 posix-acl.c:262:posix_acl_log_permit_denied

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1797099

Ravishankar N <ravishankar at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(ravishankar at redha |
                   |t.com)                      |



--- Comment #4 from Ravishankar N <ravishankar at redhat.com> ---
I think we need to find why the FOP is coming with different permissions than
what is stored in the inode context:

[2020-01-31 21:14:28.967838] I [MSGID: 139001]
[posix-acl.c:262:posix_acl_log_permit_denied] 0-data_fast-access-control:
client: CTX_ID:3b25391c-1eb3-424d-a1e8-1a2c08ffb556-GRAPH_ID:0-PID:2207
5-HOST:ovirt2.localdomain-PC_NAME:data_fast-client-1-RECON_NO:-1, gfid:
be318638-e8a0-4c6d-977d-7a937aa84806, req(uid:107,gid:107,perm:1,ngrps:4),
ctx(uid:0,gid:0,in-groups:0,perm:000,updated-
fop:INVALID, acl:-) [Permission denied]

So for gfid be318638-e8a0-4c6d-977d-7a937aa84806, a file operation came with
the permissions "req(uid:107,gid:107,perm:1,ngrps:4)"
whereas the one stored in the inode context in memory is 
"ctx(uid:0,gid:0,in-groups:0,perm:000,".
Also, the fop is also displayed as INVALID while it should have been something
like LOOKUP, WRITE etc. (i.e. whatever the fop type was). 
So I was guessing this could be due to incorrect inode context. I was hoping if
we had a test setup we could attach gdb to the brick and see what was going on.

Jiffin, do you see anything obvious in this bug?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.