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: <20100326033824.GC21658@thunk.org>
Date:	Thu, 25 Mar 2010 23:38:24 -0400
From:	tytso@....edu
To:	Jan Kara <jack@...e.cz>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH,RFC] Adding quotacheck functionality to e2fsck

On Fri, Mar 26, 2010 at 01:47:38AM +0100, Jan Kara wrote:
>   This is definitely a move in the right direction. I'd be even happier
> if e2fsck would write quota file directly - then we could just make
> quota files hidden inodes, start doing quota accounting immediately
> on mount and always do quota journaling. That would save us quite some
> trouble in kernel. The only problem with this is that we'd need to pull
> knowledge about quota formats in e2fsck...

Yes, quite possibly.  How quota is currently is set up is quite
kludgy, with magic options that do nothing but display magic options
in /proc/mounts, just in case that's a hard link to /etc/mtab.  It
also looks like that some of the magic is in various distribution's
init.d scripts, and so while I very much want to clean things up, it
wasn't clear to me how much flexibility we would have without worrying
about breaking the init scripts for Debian, Ubuntu, RHEL, SLES,
Fedora, Open SuSE, etc.

There may also be other programs that depend on the existence of
aquota.user, and may be reading and writing them in various random
ways, and there is the question of how do we provide compatibility
with these other programs, some of which may not be within quotatools,
but in various magic virtualization or container or cluster management
systems....

So maintaining compatibility between older kernels, newer kernels,
older init scripts, new init scripts, etc. may make changing the quota
system quite difficult.  I would like to do as much cleanup as we can,
though.

One question I have --- do we really have to support the 2 or 3
different quota variants?  How many people/distributions are still
using the original old quota system?  One thing that worries me is
that it looks like the old (non-journaled) quota system may be the
primary system still being used by Canonical and Debian...  I really
do hope I'm wrong, but there are a bunch of HOWTO's that still people
to use usrquota and grpquota in /etc/fstab, and not the newer
usrjquota and grpjquota mount options.

	       	     	   	   	     	 - 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ