[Gluster-devel] ./tests/bugs/snapshot/bug-1167580-set-proper-uid-and-gid-during-nfs-access.t fails if non-anonymous fds are used in read path

[Raghavendra Gowdappa]

On Thu, Aug 2, 2018 at 3:54 PM, Rafi Kavungal Chundattu Parambil <
rkavunga at redhat.com> wrote:

> Yes, I think we can mark the test as bad for now. We found two issues that
> cause the failures.
>
> One issue is with the usage of anonymous fd from a fuse mount. posix acl
> which sits on the brick graph does the authentication check during open.
> But with anonymous FD's we may not have an explicit open received before
> let's a read fop. As a result, posix acl is not getting honoured with
> anonymous fd.
>
> The second issue is with snapd and libgfapi where it uses libgfapi to get
> the information from snapshot bricks. But uid, and gid's received from a
> client are not passed through libgfapi.
>
> I will fail two separate bugs to track this issue.
>
> Since both of this issues are not relevant to the fix which Raghavendra
> send, I agree to mark the tests as bad.
>

Thanks Rafi.


>
> Regards
> Rafi KC
>
>
> ----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
> To: "Sunny Kumar" <sunkumar at redhat.com>, "Rafi" <rkavunga at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Thursday, August 2, 2018 3:23:00 PM
> Subject: Re: ./tests/bugs/snapshot/bug-1167580-set-proper-uid-and-gid-during-nfs-access.t
> fails if non-anonymous fds are used in read path
>
> I've filed  a bug to track this failure:
> https://bugzilla.redhat.com/show_bug.cgi?id=1611532
>
> As a stop gap measure I propose to mark the test as Bad to unblock patches
> [1][2]. Are maintainers of snapshot in agreement with this?
>
> regards,
> Raghavendra
>
> On Wed, Aug 1, 2018 at 10:28 AM, Raghavendra Gowdappa <rgowdapp at redhat.com
> >
> wrote:
>
> > Sunny/Rafi,
> >
> > I was trying to debug regression failures on [1]. Note that patch [1]
> only
> > disables usage of anonymous fds on readv. So, I tried the same test
> > disabling performance.open-behind
> >
> > [root at rhs-client27 glusterfs]# git diff
> > diff --git a/tests/bugs/snapshot/bug-1167580-set-proper-uid-and-
> gid-during-nfs-access.t
> > b/tests/bugs/snapshot/bug-1167580-set-proper-uid-and-
> > gid-during-nfs-access.t
> > index 3776451..cedf96b 100644
> > --- a/tests/bugs/snapshot/bug-1167580-set-proper-uid-and-
> > gid-during-nfs-access.t
> > +++ b/tests/bugs/snapshot/bug-1167580-set-proper-uid-and-
> > gid-during-nfs-access.t
> > @@ -79,6 +79,7 @@ TEST $CLI volume start $V0
> >  EXPECT_WITHIN $NFS_EXPORT_TIMEOUT "1" is_nfs_export_available
> >  TEST glusterfs -s $H0 --volfile-id $V0 $M0
> >  TEST mount_nfs $H0:/$V0 $N0 nolock
> > +TEST $CLI volume set $V0 performance.open-behind off
> >
> >  # Create 2 user
> >  user1=$(get_new_user)
> >
> >
> > With the above change, I can see consistent failures of the test just
> like
> > observed in [1].
> >
> > TEST 23 (line 154): Y check_if_permitted eeefadc
> > /mnt/glusterfs/0/.snaps/snap2/file3 cat
> > su: warning: cannot change directory to /tmp/tmp.eaKBKS0lfM/eeefadc: No
> > such file or directory
> > cat: /mnt/glusterfs/0/.snaps/snap2/file3: Permission denied
> > su: warning: cannot change directory to /tmp/tmp.eaKBKS0lfM/eeefadc: No
> > such file or directory
> > cat: /mnt/glusterfs/0/.snaps/snap2/file3: Permission denied
> > su: warning: cannot change directory to /tmp/tmp.eaKBKS0lfM/eeefadc: No
> > such file or directory
> > cat: /mnt/glusterfs/0/.snaps/snap2/file3: Permission denied
> > su: warning: cannot change directory to /tmp/tmp.eaKBKS0lfM/eeefadc: No
> > such file or directory
> > cat: /mnt/glusterfs/0/.snaps/snap2/file3: Permission denied
> >
> >
> > Test Summary Report
> > -------------------
> > ./tests/bugs/snapshot/bug-1167580-set-proper-uid-and-
> gid-during-nfs-access.t
> > (Wstat: 0 Tests: 46 Failed: 1)
> >   Failed test:  23
> >
> >
> > I had a feeling this test fails spuriously and the spurious nature is
> tied
> > with whether open-behind uses an anonymous fd or a regular fd for read.
> >
> > @Sunny,
> >
> > This test is blocking two of my patches - [1] and [2]. Can I mark this
> > test as bad and proceed with my work on [1] and [2]?
> >
> > [1] https://review.gluster.org/20511
> > [2] https://review.gluster.org/20428
> >
> > regards,
> > Raghavendra
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180802/3fb89980/attachment.html>