generic/317 and generic/318 fail un-gracefully on older kernels
which don't support userns; fix that by running a simple test
as a prerequisite and fail gracefully if needed.
Roll that in with the test for executable presence, and make
a new _require_userns()
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
generic/317 and 318 need /proc/<pid>/[uid_map|gid_map], test fail on
older kernels without that support.
Add a _require_ugid_map() function and called by 317 and 318.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>