Messages in this thread | | | Date | Mon, 7 Nov 2011 15:30:10 +0100 | From | Lennart Poettering <> | Subject | Re: [RFC PATCH] tmpfs: support user quotas |
| |
On Mon, 07.11.11 13:58, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
> > > Right, rlimit approach guarantees a simple way of dealing with users > > across all tmpfs instances. > > Which is almost certainly not what you want to happen. Think about direct > rendering.
I don't see what direct rendering has to do with closing the security hole that /dev/shm currently is.
> For simple stuff tmpfs already supports size/nr_blocks/nr_inodes mount > options so you can mount private resource constrained tmpfs objects > already without kernel changes. No rlimit hacks needed - and rlimit is > the wrong API anyway.
Uh? I am pretty sure we don't want to mount a private tmpfs for each user in /dev/shm and /tmp. If you have 500 users you'd have 500 tmpfs on /tmp and on /dev/shm. Despite that without some ugly namespace hackery you couldn't make them all appear in /tmp as /dev/shm without subdirectories. Don't forget that /dev/shm and /tmp are an established userspace API.
Resource limits are exactly the API that makes sense here, because:
a) we only want one tmpfs on /tmp, and one tmpfs on /dev/shm, not 500 on each for each user
b) we cannot move /dev/shm, /tmp around without breaking userspace massively
c) we want a global limit across all tmpfs file systems for each user
d) we don't want to have to upload the quota database into each tmpfs at mount time.
And hence: a per user RLIMIT is exactly the minimal solution we want here.
Lennart
-- Lennart Poettering - Red Hat, Inc.
| |