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
| ||
|
Date: Mon, 3 May 2010 13:19:44 +0530 From: Nikanth Karthikesan <knikanth@...e.de> To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, coly.li@...e.de, Nick Piggin <npiggin@...e.de>, Alexander Viro <viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>, Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org, Eelis <opensuse.org@...tacts.eelis.net>, Amit Arora <aarora@...ibm.com>, Christoph Hellwig <hch@...radead.org> Subject: Re: [PATCH] Prevent creation of files larger than RLIMIT_FSIZE using fallocate On Monday 03 May 2010 12:29:45 Amit K. Arora wrote: > On Mon, May 03, 2010 at 09:53:44AM +0530, Nikanth Karthikesan wrote: > > On Saturday 01 May 2010 12:34:26 Amit K. Arora wrote: > > > On Fri, Apr 30, 2010 at 02:33:19PM -0700, Andrew Morton wrote: > > > > Also, there doesn't seem to be much point in doing > > > > > > > > mutex_lock(i_mutex); > > > > if (some_condition) > > > > bale out > > > > mutex_unlock(i_mutex); > > > > > > > > <stuff> > > > > > > > > because `some_condition' can now become true before or during the > > > > execution of `stuff'. > > > > > > > > IOW, it's racy. > > > > oh, yes. :( > > > > > Agreed. How about doing this check in the filesystem specific fallocate > > > inode routines instead ? For example, in ext4 we could do : > > > > I guess, calling the filesystem specific fallocate with the lock held > > would create lock ordering problems? If so, this might be the only way. > > But it would be better to document at the call site, that the callee > > should check for RLIMIT_FSIZE. > > Hmm.. I never said to call the filesystem specific fallocate with > i_mutex held. What I suggested was that each filesystem at some point > anyhow takes the i_mutex to preallocate. Thats where the check should > be, to avoid the race. This is what the example patch below does. > Yes, you never said that. But I just wondered whether that would be have problems and doing the check in filesystem specific fallocate is the only solution. :) Thanks Nikanth -- 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