Re: xfstests 317

Re: xfstests 317

[Christoph Hellwig]

On Thu, Oct 24, 2013 at 04:25:57PM -0400, Dwight Engen wrote:
> On Thu, 24 Oct 2013 09:12:35 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > This one also seems to be guranteed to fail for me with the following
> > output:
> > 
> > 
> > --- tests/generic/317.out	2013-09-09 14:41:08.000000000 +0000
> > +++ /root/xfstests/results//generic/317.out.bad	2013-10-24
> > 16:12:00.000000000 +0000 @@ -4,9 +4,7 @@
> >    Size: 0            Filetype: Regular File
> >    Mode: (0644/-rw-r--r--)         Uid: (qa_user)  Gid: (qa_user)
> >  From user_ns
> > -  File: "$SCRATCH_MNT/file1"
> > -  Size: 0            Filetype: Regular File
> > -  Mode: (0644/-rw-r--r--)         Uid: (0)  Gid: (0)
> > +execvp: Permission denied
> 
> Hi Christoph,
> 
> Hmm, this looks to me like src/lstat64 cannot be exec()ed by qa_user on
> your system. Is there some other id I can/should use?

That doesn't seem to be the issue from the main system for me:

root@vm:~/xfstests# sudo -u fsgqa ./src/lstat64
Usage: lstat64 [-t] filename ...

Do you have a one liner to try what happens in a namespace?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstests 317

[Dwight Engen]

On Fri, 25 Oct 2013 02:33:33 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Thu, Oct 24, 2013 at 04:25:57PM -0400, Dwight Engen wrote:
> > On Thu, 24 Oct 2013 09:12:35 -0700
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > This one also seems to be guranteed to fail for me with the
> > > following output:
> > > 
> > > 
> > > --- tests/generic/317.out	2013-09-09 14:41:08.000000000
> > > +0000 +++ /root/xfstests/results//generic/317.out.bad
> > > 2013-10-24 16:12:00.000000000 +0000 @@ -4,9 +4,7 @@
> > >    Size: 0            Filetype: Regular File
> > >    Mode: (0644/-rw-r--r--)         Uid: (qa_user)  Gid: (qa_user)
> > >  From user_ns
> > > -  File: "$SCRATCH_MNT/file1"
> > > -  Size: 0            Filetype: Regular File
> > > -  Mode: (0644/-rw-r--r--)         Uid: (0)  Gid: (0)
> > > +execvp: Permission denied
> > 
> > Hi Christoph,
> > 
> > Hmm, this looks to me like src/lstat64 cannot be exec()ed by
> > qa_user on your system. Is there some other id I can/should use?
> 
> That doesn't seem to be the issue from the main system for me:
> 
> root@vm:~/xfstests# sudo -u fsgqa ./src/lstat64
> Usage: lstat64 [-t] filename ...
> 
> Do you have a one liner to try what happens in a namespace?

Hi Cristoph, on my system (where fsgqa is id 501) the one liner the
test is running is:

# ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
Usage: lstat64 [-t] filename ...

Since you are getting to the point where it is trying to print out the
ids, that means you already ran nsexec once for the touch command to
create the file, which is why I think it is something to do with
exec()ing lstat64. You could try replacing the 501 in the -G with the
group id of fsgqa since it is possibly not 501 also, but I don't see
how that is the problem.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstests 317

[Christoph Hellwig]

On Mon, Oct 28, 2013 at 11:43:28AM -0400, Dwight Engen wrote:
> Hi Cristoph, on my system (where fsgqa is id 501) the one liner the
> test is running is:
> 
> # ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
> Usage: lstat64 [-t] filename ...

The id here is 1000 and the following works just fine:

/src/nsexec -s -U -M "0 1000 1000" -G "0 1000 1000" ./src/lstat64
Usage: lstat64 [-t] filename ...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfstests 317

[Christoph Hellwig]

On Wed, Oct 30, 2013 at 09:19:55AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 28, 2013 at 11:43:28AM -0400, Dwight Engen wrote:
> > Hi Cristoph, on my system (where fsgqa is id 501) the one liner the
> > test is running is:
> > 
> > # ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
> > Usage: lstat64 [-t] filename ...
> 
> The id here is 1000 and the following works just fine:
> 
> /src/nsexec -s -U -M "0 1000 1000" -G "0 1000 1000" ./src/lstat64
> Usage: lstat64 [-t] filename ...

But:

./src/nsexec -s -U -M "0 1000 1000" -G "0 501 1000" /root/xfstests/src/lstat64
execvp: Permission denied


Which is probably due to:
root@vm:~/xfstests# ls -ld ~ 
drwx------ 6 root root 4096 Oct 30 16:24 /root


Guess we need a relative path here?

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH] xfstests: generic/317 use relative paths to avoid traversal permission problems

[Dwight Engen]

On Wed, 30 Oct 2013 09:24:41 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Oct 30, 2013 at 09:19:55AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 28, 2013 at 11:43:28AM -0400, Dwight Engen wrote:
> > > Hi Cristoph, on my system (where fsgqa is id 501) the one liner
> > > the test is running is:
> > > 
> > > # ./src/nsexec -s -U -M "0 501 1000" -G "0 501 1000" ./src/lstat64
> > > Usage: lstat64 [-t] filename ...
> > 
> > The id here is 1000 and the following works just fine:
> > 
> > /src/nsexec -s -U -M "0 1000 1000" -G "0 1000 1000" ./src/lstat64
> > Usage: lstat64 [-t] filename ...
> 
> But:
> 
> ./src/nsexec -s -U -M "0 1000 1000" -G "0 501
> 1000" /root/xfstests/src/lstat64 execvp: Permission denied
> 
> 
> Which is probably due to:
> root@vm:~/xfstests# ls -ld ~ 
> drwx------ 6 root root 4096 Oct 30 16:24 /root
> 
> 
> Guess we need a relative path here?

Yep, that makes sense. I modeled this on 219 which was using
$here/src/lstat64 but didn't think about the fact that in my test fsgqa
might have traversal problems. I see plenty of other tests are using
relative paths so the following patch should (hopefully) fix 317 for you.
Thanks for tracking it down.

--

Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
---
 tests/generic/317 |    8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)
 mode change 100644 => 100755 tests/generic/317

diff --git a/tests/generic/317 b/tests/generic/317
old mode 100644
new mode 100755
index 6d8d3c4..f5d1b21
--- a/tests/generic/317
+++ b/tests/generic/317
@@ -46,8 +46,6 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 . ./common/filter
 . ./common/attr
 
-nsexec=$here/src/nsexec
-lstat64=$here/src/lstat64
 file=$SCRATCH_MNT/file1
 
 # real QA test starts here
@@ -75,10 +73,10 @@ _filter_output()
 _print_numeric_uid()
 {
     echo "From init_user_ns"
-    $here/src/lstat64 $file |head -3 |_filter_output
+    src/lstat64 $file |head -3 |_filter_output
 
     echo "From user_ns"
-    $nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" $here/src/lstat64 $file |head -3 |_filter_output
+    src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" src/lstat64 $file |head -3 |_filter_output
 }
 
 umount $SCRATCH_DEV >/dev/null 2>&1
@@ -89,7 +87,7 @@ _scratch_mount      >>$seqres.full 2>&1 || _fail "mount failed"
 chmod 777 $SCRATCH_MNT
 
 # create $file as "root" in userns, which is $qa_user in parent namespace
-$nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" touch $file
+src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" touch $file
 
 _print_numeric_uid
 
-- 
1.7.1

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: generic/317 use relative paths to avoid traversal permission problems

[Christoph Hellwig]

On Wed, Oct 30, 2013 at 02:30:50PM -0400, Dwight Engen wrote:
> Yep, that makes sense. I modeled this on 219 which was using
> $here/src/lstat64 but didn't think about the fact that in my test fsgqa
> might have traversal problems. I see plenty of other tests are using
> relative paths so the following patch should (hopefully) fix 317 for you.
> Thanks for tracking it down.

Thanks, this fixes the problem for me.

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH] xfstests: generic/317 use relative paths to avoid traversal permission problems

[Rich Johnston]

This has been committed.

Thanks
--Rich

commit 4818302fbf5c4c64dbe2fb3e504e71ceafff50e3
Author: Dwight Engen <dwight.engen@oracle.com>
Date:   Wed Oct 30 18:30:50 2013 +0000

     xfstests: generic/317 use relative paths to avoid traversal 
permission problems

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH xfstests] generic/317: Use relative paths to avoid traversal permission problems

[Zhihao Cheng]

generic/317 will fail because execvp(cmd) is executed without permission,
where cmd is '$here/src/lstat64 $file', which is called by
  $here/src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000"\
  $here/src/lstat64 $file

So, you will see following output:
  From user_ns
  ...
  +execvp: Permission denied

nsexec runs the instruction '$here/src/lstat64 $file' as a regular user,
the regular user may not have permission to access path in '$here'.

Actually, it has been fixed in 4818302fbf ("xfstests: generic/317 use
relative paths..."), which then been modified by b7cecbea22 ("fstests:
Add path $here before src/<file>").

Fixes: b7cecbea22 ("fstests: Add path $here before src/<file>")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
---
 tests/generic/317 | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/generic/317 b/tests/generic/317
index 509887d..8ea9d81 100755
--- a/tests/generic/317
+++ b/tests/generic/317
@@ -61,7 +61,10 @@ _print_numeric_uid()
     $here/src/lstat64 $file |head -3 |_filter_output
 
     echo "From user_ns"
-    $here/src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" $here/src/lstat64 $file |head -3 |_filter_output
+    # don't use $here/src/lstat64, as we're running cmd(src/lstat64) in
+    # nsexec as a regular user, and $here may contain path component that
+    # a regular user doesn't have search permission
+    $here/src/nsexec -s -U -M "0 $qa_user_id 1000" -G "0 $qa_user_id 1000" src/lstat64 $file |head -3 |_filter_output
 }
 
 _scratch_unmount >/dev/null 2>&1
-- 
2.7.4