[Bugs] [Bug 1392772] [setxattr_cbk] "Permission denied" warning messages are seen in logs while running pjd-fstest suite

[bugzilla at redhat.com]

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



--- Comment #5 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Raghavendra G from comment #4)
> Except for how mkdir by non-root user succeeded in my test above, other
> things can be answered.

<raghug> I think the bug was a special case
<raghug> look at this comment
<raghug> The setxattr fails, due to the permissions on the directory being 0464
(set during the mkdir as requested by the call), where user has only READ
permissions, and posix_acl xlator checks that the UID of the setxattr caller
(internal DHT request above) is the same as the UID of the directory inode, and
hence evaluates permissions based on this, which evaluates to READ ONLY and
denies the setxattr from proceeding.
<nbalacha> the bug was using the mode to create the dir
<nbalacha> yes
<nbalacha> the user creates a dir with read perms
<raghug> that explains
<raghug> thanks
<nbalacha> which is why I asked if you had used the mode :)
<raghug> I didn't get that. Sorry :)
<nbalacha> yesterday - I asked if you had used -m in the mkdir
<nbalacha> because the test on which the bug was reported does
<raghug> no.. I meant I didn't realize the importance of mode :)
<nbalacha> so the mkdir ops in posix uses that and the perms are changed
immediately
<nbalacha> ah ok
<nbalacha> so posix acl check fails because the layout set is a write 
<nbalacha> and there is no write perm
<nbalacha> ideally we need to relook at the whole thing
<nbalacha> this is a hacky way to fix things
<raghug> the whole root of confusion was, I was wondering if the user can
create a directory he'll have write permissions
<nbalacha> we need special internal ops and a way to bypass checks for those
<raghug> didn't realize that mode alters that

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TMYUDtgB3l&a=cc_unsubscribe