linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: Davidlohr Bueso <dave@gnu.org>,
	Lennart Poettering <mzxreary@0pointer.de>,
	Christoph Hellwig <hch@infradead.org>,
	Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH] tmpfs: support user quotas
Date: Mon, 7 Nov 2011 22:53:14 +0000	[thread overview]
Message-ID: <20111107225314.0e3976a6@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <CAPXgP117Wkgvf1kDukjWt9yOye8xArpyX29xx36NT++s8TS5Rw@mail.gmail.com>

> What part of the message did you read? This is about _per_user_
> limits, not global limits!

What part of 'we support lots of mounts' don't you understand. Or perhaps
you could go use a control group for it ?

> Any untrusted user can fill /dev/shm today and DOS many services that
> way on any machine out there. Same for /tmp when it's a tmpfs, or
> /run/user. This is an absolutely unacceptable state and needs fixing.

Actually if you've mounted it with limits they can be a nuisance but
little more, and if you are running with memory overcommit disabled then
its accounted for in that. If you are running with memory over commit
allowed (as eg Red Hat and Fedora do) you are peeing into the wind at this
point anyway so wasting time.

> I don't care about which interface it is, if someting else fits
> better, let's discuss that, but it has surely absolutely noting to do
> with size/nr_blocks/nr_inodes.

Per user would be quota, per process would be rlimit. Quite simple
really, nice standard interfaces we've had for years. Various systems
have been quotaing /tmp/ for a long time. Smart secure ones of course
mount a per user /tmp via PAM or similar to avoid /tmp attacks and in that
case the mount options I pointed out already do the job.

Quota isn't entirely trivial because you want your quota db initialised
at mount so you'd need to pass a quota file pointer to the mount command
ideally. All doable however and makes the management easy and means you
get all the application expected behaviour when you exceed your limits
(that is for properly written stuff - lots of crappy badly written desktop
programs randomly crash or worse as we already know)

This is why I'm confused - you are wittering about all sorts of security
stuff but you are not addressing the more serious matters first - the
ones that go beyond a DoS.

Alan

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-11-07 22:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06 21:15 Davidlohr Bueso
2011-11-06 22:10 ` Lennart Poettering
2011-11-07  7:31 ` Christoph Hellwig
2011-11-07 11:29   ` Lennart Poettering
2011-11-07 14:20     ` Davidlohr Bueso
2011-11-07 13:58       ` Alan Cox
2011-11-07 14:27         ` Kay Sievers
2011-11-07 22:53           ` Alan Cox [this message]
2011-11-07 22:57             ` Glauber Costa
2011-11-07 23:07             ` Lennart Poettering
2011-11-07 23:43               ` Alan Cox
2011-11-08  0:25                 ` Lennart Poettering
2011-11-08  0:46                   ` Alan Cox
2011-11-07 14:30         ` Lennart Poettering
2011-11-07 22:15           ` KOSAKI Motohiro
2011-11-07 22:37             ` Kay Sievers
2011-11-08  0:33               ` KOSAKI Motohiro
2011-11-07 23:01           ` Alan Cox
2011-11-07  9:11 ` Valdis.Kletnieks
2011-11-07 14:49   ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111107225314.0e3976a6@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=dave@gnu.org \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mzxreary@0pointer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox