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:	Thu, 14 Jul 2016 15:13:31 +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 Tue 12-07-16 12:15:47, Ted Tso wrote:
> On Tue, Jul 12, 2016 at 12:59:08PM +0200, Jan Kara wrote:
> > 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.
> 
> That would be good, since at the moment to determine whether or not
> quota enforcement is enabled or not.

This is now done.

> > 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?
> 
> That seems reasonable.  The only concern is that it might be confusing
> for people who are using older, legacy quota setups, but given that
> usrquota would cause enforcing plus accounting to be enabled, it
> shouldn't cause a problem.

Yes, my thinking about this was that when you transfer from a legacy quota
setup to the latest one with hidden quota files, you have to somewhat
update your mindset anyway (e.g. quota information is now created using
tune2fs / mke2fs and checked using e2fsck instead of quotacheck(8)). So the
fact that you won't need quotaon(8) is only a small addition to that.

> I think aligning with XFS so that the user experience for quota should
> be as identical as possible regardless of which file system is being
> used makes a lot of sense, especially since you've been adding a bunch
> of the plumbing for quotactl to make this possible.
> 
> On the kernel side this means that teaching ext4 so that if the
> usrquota monut option is specified, quota enforcing will be enabled.
> We should make the necessary changes in kernel and possily quota-tools
> so that quotaoff can also disable quota enforcing (just like with
> XFS).
> 
> Does that sound like a plan?

Yes. quotaoff will already disable only enforcement for ext4 with hidden
quota files so there's no need to change anything there. We just need to
add kernel support for enabling quota enforcement based on mount option. 
Attached patch should do that - I still need to test whether it doesn't
break anything so don't apply it yet, just have a look whether it looks
sane to you.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

View attachment "0001-ext4-Enable-quota-enforcement-based-on-mount-options.patch" of type "text/x-patch" (5072 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ