[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150316232434.GJ28557@dastard>
Date: Tue, 17 Mar 2015 10:24:34 +1100
From: Dave Chinner <david@...morbit.com>
To: David Drysdale <drysdale@...gle.com>
Cc: linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Kees Cook <keescook@...omium.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Meredydd Luff <meredydd@...atehouse.org>,
Will Drewry <wad@...omium.org>,
Jorge Lucangeli Obes <jorgelo@...gle.com>,
Ricky Zhou <rickyz@...gle.com>,
Lee Campbell <leecam@...gle.com>,
Julien Tinnes <jln@...gle.com>,
Mike Depinet <mdepinet@...gle.com>,
James Morris <james.l.morris@...cle.com>,
Andy Lutomirski <luto@...capital.net>,
Paolo Bonzini <pbonzini@...hat.com>,
Paul Moore <paul@...l-moore.com>,
Christoph Hellwig <hch@...radead.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
linux-api@...r.kernel.org, linux-security-module@...r.kernel.org,
fstests@...r.kernel.org
Subject: Re: [PATCHv3 xfstests 2/3] generic: test openat and new O_BENEATH
flag
On Mon, Mar 09, 2015 at 02:00:11PM +0000, David Drysdale wrote:
> Test basic openat(2) behaviour.
>
> Test that if O_BENEATH flag is set, openat() will only
> open paths that have no .. component and do not start
> with /. Symlinks are also checked for the same restrictions.
>
> Signed-off-by: David Drysdale <drysdale@...gle.com>
> ---
> .gitignore | 1 +
> common/openat | 61 ++++++++++++++++++++++++++++++
> src/Makefile | 3 +-
> src/openat.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++
This strikes me as something that shoul dbe added to xfs_io for
testing, as it already supports a heap of other open flags and
xfstests is already dependent on it.
> tests/generic/151 | 89 ++++++++++++++++++++++++++++++++++++++++++++
> tests/generic/151.out | 9 +++++
> tests/generic/152 | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++
> tests/generic/152.out | 23 ++++++++++++
> tests/generic/group | 2 +
I'd also prefer one patch per new test - it's easier to review...
> +_openat_setup()
> +{
> + local dir=$1
> +
> + mkdir -p $dir/subdir
> + echo 0123456789 > $dir/topfile
> + echo 0123456789 > $dir/subdir/bottomfile
> +
> + ln -s subdir/bottomfile $dir/symlinkdown
> + ln -s ../topfile $dir/subdir/symlinkup
> + ln -s $dir/topfile $dir/subdir/symlinkout
> + ln -s bottomfile $dir/subdir/symlinkin
> +}
> +
> +#
> +# Check whether the openat wrapper program is available
> +#
> +_requires_openat()
> +{
> + OPENAT_PROG=$here/src/openat
> + _require_command $OPENAT_PROG
> +}
if this is part of xfs_io, then _requires_xfs_io_command "open -b"
could be used to test if the command is supported, and no need for
this function at all.
> +#
> +# This checks whether the O_BENEATH flag is supported by the openat syscall
> +#
> +_requires_o_beneath()
> +{
> + # Kernels that don't support O_BENEATH will silently accept it, so
> + # check for O_BENEATH behavior: attempting to open an absolute
> + # path should fail with EPERM.
> + $OPENAT_PROG -t -b $TEST_DIR
> + if [ $? -ne 0 ]; then
> + _notrun "kernel doesn't support O_BENEATH flag in openat syscall"
> + fi
> +}
as running the command would tell us if the kernel supports it, too.
> +#endif
> +#endif
> +
> +void usage(const char *progname)
> +{
> + fprintf(stderr, "Usage: %s [-f dirname] [-b] [-n] [-t] <file>\n",
> + progname);
> + fprintf(stderr," -f dirname : use this dir for dfd\n");
> + fprintf(stderr," -b : open with O_BENEATH\n");
> + fprintf(stderr," -n : open with O_NOFOLLOW\n");
> + fprintf(stderr," -t : test for expected EPERM failure\n");
> + fprintf(stderr," -h : show this usage message\n");
> + exit(1);
Hmm - you're also testing O_NOFOLLOW behaviour too? Perhaps that
should be mentioned/added to xfs_io, too?
The reason I suggest this, even though it's a little more work, is
tht we can then re-use the new flags in other tests easily without
needing to write new helper functions...
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists