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]
Date:	Tue, 12 Jul 2016 12:59:08 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Kara <jack@...e.cz>, Eric Sandeen <sandeen@...deen.net>,
	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 Mon 11-07-16 13:12:42, Ted Tso wrote:
> On Mon, Jul 11, 2016 at 06:15:56PM +0200, Jan Kara wrote:
> > 
> > What would you like to achieve with this? There is 'QF_META' format which
> > is different from 'QF_XFS' format basically only in the set of quotactls
> > used. As I said above it might be nice to separate kernel-api from the
> > underlying-quota-format but in reality these two were bound together in
> > older kernels so they are not really independent.
> 
> The main reason why I noticed is with the new (err, "latest") ext4
> quota (enabled via mke2fs -t ext4 -O quota) implementation, we enable
> quota tracking at mount time.  (This may be true with journalled quota
> as well, actually).  But we don't actually enable quota *enforcement*
> until quotaon is given.

Yes.

> The problem is that quotaon -p prints the status of whether or not
> quota *tracking* is enabled, and with the new ext4 quota, quota
> tracking is *always* enabled.  So quota -p doesn't report anything
> useful for new ext4 quota systems, and when I started to look at how
> to change things, that's when I noticed that we weren't using the new
> quotactl commands with ext4 even though they worked, and that the new
> quotactl implementation had more functionality than the older ones.

OK. But with XFS you'd notice that quotaon -p also returns 'on' whenever
the accounting is turned on. So ext4 and xfs behave in the same way.
Arguably it would be more useful if quotaon -p reported 'off', 'accounting',
'enforcement'. Maybe I'll do that.

> BTW, I've seriously been thinking about changing the default so that
> if you use mke2fs -O quota, quota enforcement is also enabled by
> default at mount time, and we use a mount option to disable quota
> enforcement.  If we then added a way of selectively enabling and
> disabling quota enforcement via quota-tools, then we would be bringing
> behaivour of how ext4 quota works to like how xfs treats quota.  The
> question I have is how to do this in a way that isn't surprising for
> people who are used to the old behaviour --- but mke2fs -O quota is
> still relatively new, so maybe we could get away with it without
> having to add more superblock flags.

So currently if you use quotaon(8) it will turn on/off only enforcement in
ext4 (accounting is always on when the feature is enabled) - don't get
confused with 'quotaon -p' output - that tests something different.

Speaking of automatic enabling of quota enforcement: I wanted to keep the
old behavior where no enforcement happens until you run quotaon(8) which is
how things traditionally worked for ext2/3/4. That's why things default to
having enforcement off. If we want to make things more consistent with XFS,
one option I can see is that when e.g. 'usrquota' mount option is set, then
user quota enforcement will be turned on. That is essentially how XFS
works (including the mount option name). What do you think?

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ