linux-ext4 - Re: [PATCH v2] xfstests, generic: add project quota attribute tests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160708050228.GH19871@thunk.org>
Date:	Fri, 8 Jul 2016 01:02:28 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...deen.net>
Cc:	Dave Chinner <david@...morbit.com>,
	Wang Shilong <wangshilong1991@...il.com>,
	fstests@...r.kernel.org, linux-ext4@...r.kernel.org,
	sihara@....com, lixi@....com, Wang Shilong <wshilong@....com>
Subject: Re: [PATCH v2] xfstests, generic: add project quota attribute tests

On Thu, Jul 07, 2016 at 10:19:27PM -0500, Eric Sandeen wrote:
> 
> But the point I keep trying to make - and failing, apparently - 
> is that we will / should have two sets of tests for userspace
> functionality at least; one using standard quota tools, and one
> using xfs_quota.  Both should test the same kernel paths, but
> if we want to know that userspace is working we need to test both.

I agree completely that we should test both userspace stacks.  Where I
disagree is whether this has anything to do with using the usrquota
and grpquota mount options, and which ext4 mkfs options are used to
set up quota or project quota support.  That's a completely orthogonal
issue.

> I don't know how we got to the point where we have 2 parallel
> quota infrastructures, it's an unfortunate mess IMHO.  :(

Actually, I've been staring at the quotatools source code and it's
even more complicated than that.  There are newer quotactl
subcommands, such as Q_XGETQSTAT and Q_XGETQSTATV, which currently
quotatools only tries using if it thinks the quota format (which in
this sense seems to be system API, not the actual quota file format
--- these two concepts seem to have been overloaded at some point) is
"xfs".

Currently quotatools only assumes the "xfs" quota format should be
used for "xfs" and "gfs" --- but it works for other file systems,
including ext4 as well.  As a result, there's certain information,
such as whether ext4 is doing limits enforcement as well as quota
tracking, which is *not* being exposed to the user.  I suspect one of
the reasons for this is the tests in quotatools for which kernel
interfaces are present are fairly primitive, and in fact there are
some comments in quotasys.c which makes references to behaviours of
certain specific Red Hat kernel versions to decide which interfaces
are available.  :-(

And if we just did the simple thing to enable use of the "new" (aka
"xfs", although this is ***massive*** misnomer) quota format in
quotatools, it would break if the latest quota tools were ever
compiled on older Enterprise Linux systems.

Ugh.  I suspect one of the reasons why things have gotten into such a
mess is that quota is mostly an enterprise feature, and most community
distros and community users/kernel developers don't really use it.  As
a result, no one has bothered to put in clean ways of doing interface
versioning, as I suspect a lot of work happens right before the
Enterprise Linux cutoff date, and there isn't much incentive to clean
things up afterwards.

> But if we want to test xfs_quota tests on ext4, we still
> need to know that e2fsprogs is pquota-capable.
> 
> If we want to test standard quota tools on ext4, we need to know
> that *those* binaries are capable, as well as e2fsprogs.  etc...

Completely agree.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html