[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 bugzilla at redhat.com
Fri Feb 28 05:42:47 UTC 2020


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

Krutika Dhananjay <kdhananj at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(kdhananj at redhat.c |
                   |om)                         |



--- Comment #6 from Krutika Dhananjay <kdhananj at redhat.com> ---
(In reply to Jiffin from comment #5)
> (In reply to Ravishankar N from comment #4)
> > 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?
> 
> I came to know it is shard volume, I am not sure how acl xlator works with
> all the shards, do it develops ctx for each shard or only the head.

At the posix acl layer, different shards will be treated as separate inodes. So
the special knowledge that they are shards won't exist in the brick stack.

Secondly, the gfid in the log message above -
be318638-e8a0-4c6d-977d-7a937aa8480 - suggests it's "/.shard" directory, not a
shard file as such.

-Krutika

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


More information about the Bugs mailing list