linux-ext4 - Re: 3.10.10: quota problems

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131016022548.GB28823@thunk.org>
Date:	Tue, 15 Oct 2013 22:25:48 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Carlos Carvalho <carlos@...ica.ufpr.br>, linux-ext4@...r.kernel.org
Subject: Re: 3.10.10: quota problems

On Tue, Oct 15, 2013 at 05:53:34PM +0200, Jan Kara wrote:
> On Fri 11-10-13 20:25:41, Carlos Carvalho wrote:
>   No idea here, sorry. I will try to reproduce the problem and see what I
> can find. I'd just note that userspace support of hidden quotas in
> e2fsprogs is still experimental and Ted pointed out a few problems in it.
> Among others I think limits are not properly transferred from old to new
> quota file during fsck... But it still doesn't explain why the limits got
> lost after the crash.

This is a known bug, alas.  mke2fs -O quota directs the user to read:

https://ext4.wiki.kernel.org/index.php/Quota

for a list of caveats, including:

  Support for the quota feature first appeared in e2fsprogs 1.42,
  although it is not enabled by default. It must enabled via a
  compile-time configuration option, --enable-quota. There are bug fixes
  which have been applied in various 1.42.x maintenance branch releases,
  so users who wish to experiment with the quota feature are strongly
  encouraged upgrade to the latest e2fsprogs 1.42.x maintenance
  release. As of this writing the following bugs are still in e2fsprogs
  1.42.7, which means use of file systems with the quota feature in
  production can not be recommended:

    * The e2fsck check of the on-disk quota inodes won't notice if
      there is a missing uid record. (i.e., if some uid, say daemon
      owns a bunch of files, but that uid record is not in the quota
      inode, e2fsck won't say boo.)

    * If e2fsck *does* notice a discrepancy between the usage
      information recorded in the hidden quota inodes, and the actual
      number of blocks used by a particular user id or group id, it
      will overwrite the user or group quota inode with all of the
      information it has. Unfortunately, in the process it will zero
      out all of the current quota limits set. This is unfortunate....

The problem is that the person who originally contributed the code was
working in an environment where they only needed usage tracking, and
they weren't using quota enforcement.  So the fact that the e2fsck
code that was submitted was incomplete wasn't something that got
noticed right away.

It's been on my todo list to fix, but I just haven't had time to get
to it.  :-(   Part of the problem is that it requires some fairly major
restructuring in how the quota support is handled in e2fsprogs.

						- 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