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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <21086.236.420841.123331@fisica.ufpr.br>
Date:	Tue, 15 Oct 2013 23:58:52 -0300
From:	Carlos Carvalho <carlos@...ica.ufpr.br>
To:	linux-ext4@...r.kernel.org
Subject: Re: 3.10.10: quota problems

Theodore Ts'o (tytso@....edu) wrote on 15 October 2013 22:25:
 >  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:

That's why I'm using 1.42.8, the latest version.

 >    * 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....

Unfortunate indeed but I can work around it. What's really bad is
*wrong usage*:

cyre#~ quota -v user1
Disk quotas for user user1 (uid 634): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
       /dev/md3       0       0       0               0       0       0        

cyre#~ du -s ~user1
161M	/home/users/user1

ls -l ~user1 shows lots of files belonging to user1. For myself:

cyre%~[23:42] quota -v
Disk quotas for user carlos (uid 577): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
       /dev/md3  721680       0       0           51064       0       0        

cyre%~[23:42]  du -s .
13,6G	.

How can this be? Looks like a kernel problem.
--
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