From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with SMTP id 32DB96B0069 for ; Mon, 7 Nov 2011 07:17:52 -0500 (EST) Received: from damascus.uab.es ([127.0.0.1]) by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (built Jan 6 2005)) with ESMTP id <0LUA00LGCI50F700@damascus.uab.es> for linux-mm@kvack.org; Mon, 07 Nov 2011 13:17:25 +0100 (CET) Received: from aomail.uab.es ([158.109.65.1]) by damascus.uab.es (Sun Java System Messaging Server 6.1 HotFix 0.10 (builtJan 6 2005)) with ESMTP id <0LUA005F5I501V50@damascus.uab.es> forlinux-mm@kvack.org; Mon, 07 Nov 2011 13:17:24 +0100 (CET) Date: Mon, 07 Nov 2011 15:20:07 +0100 From: Davidlohr Bueso Subject: Re: [RFC PATCH] tmpfs: support user quotas In-reply-to: <20111107112952.GB25130@tango.0pointer.de> Message-id: <1320675607.2330.0.camel@offworld> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT References: <1320614101.3226.5.camel@offbook> <20111107112952.GB25130@tango.0pointer.de> Sender: owner-linux-mm@kvack.org List-ID: To: Lennart Poettering Cc: Christoph Hellwig , Hugh Dickins , Andrew Morton , lkml , linux-mm@kvack.org, Kay Sievers On Mon, 2011-11-07 at 12:29 +0100, Lennart Poettering wrote: > On Mon, 07.11.11 02:31, Christoph Hellwig (hch@infradead.org) wrote: > > > > > On Sun, Nov 06, 2011 at 06:15:01PM -0300, Davidlohr Bueso wrote: > > > From: Davidlohr Bueso > > > > > > This patch adds a new RLIMIT_TMPFSQUOTA resource limit to restrict an individual user's quota across all mounted tmpfs filesystems. > > > It's well known that a user can easily fill up commonly used directories (like /tmp, /dev/shm) causing programs to break through DoS. > > > > Please jyst implement the normal user/group quota interfaces we use for other > > filesystem. > > Please don't. > > tmpfs by its very nature is volatile, which means that we'd have to > upload the quota data explicitly each time we mount a tmpfs, which means > we'd have to add quite some userspace infrastructure to make tmpfs work > with quota. Either every time a tmpfs is mounted we'd have to apply a > quota for every configured user and every future user to it (which is > simply not realistic) or on every user logging in we'd have to go > through all tmpfs mount points and apply a user-specific quota setting > to it -- which isn't much less ugly and complex. Just using a > user-specific RLIMIT is much much simpler and beautiful there, and > requires almost no changes to userspace. > > On top of that I think a global quota over all tmpfs is actually > preferable than a per-tmpfs quota, because what you want to enforce is > that clients cannot drain the pool that tmpfs is backed from but how > they distribute their share of that pool on the various tmpfs mounted > doesn't really matter in order to avoid DoS vulnerabilities. Right, rlimit approach guarantees a simple way of dealing with users across all tmpfs instances. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org