tmpfs: support user quotas

From: Davidlohr Bueso <[email protected]>

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.

From: Davidlohr Bueso <[email protected]>

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.

Quoted 4 lines · Davidlohr Bueso

From: Davidlohr Bueso <[email protected]>

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.

Quoted 9 lines · Christoph Hellwig

Quoted 4 lines · Davidlohr Bueso

From: Davidlohr Bueso <[email protected]>

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.

Quoted 2 lines

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.

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.

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

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.

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.

Quoted 2 lines

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 ?

Quoted 3 lines

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.

Quoted 3 lines

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 [email protected]. 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:"[email protected]"> [email protected]</a>

Per user would be quota, per process would be rlimit. Quite simple really, nice standard interfaces we've had for years. Various systems

Quoted 2 lines · Alan Cox

Per user would be quota, per process would be rlimit. Quite simple really, nice standard interfaces we've had for years. Various systems

Uh, have you ever really looked at resource limits? Some of them are per-user, not per-process, i.e. RLIMIT_NPROC. And this would just be another one.

Quoted 2 lines · On Tue, 8 Nov 2011 00:07:12 +0100 Lennart Poettering <[email protected]>…

On Mon, 07.11.11 22:53, Alan Cox ([email protected]) wrote:

Quoted 6 lines

Quoted 2 lines

Per user would be quota, per process would be rlimit. Quite simple really, nice standard interfaces we've had for years. Various systems

Uh, have you ever really looked at resource limits? Some of them are per-user, not per-process, i.e. RLIMIT_NPROC. And this would just be another one.

NPROC is a bit of an oddity.

And the standards have no idea how a resource limit hit for an fs would be reported, nor how an app installer would check for it. Quota on the other hand is defined behaviour.

And half of the other resource limits are "oddities" too? For example RLIMIT_SIGPENDING is per-user and so is RLIMIT_MSGQUEUE, and others too.

Quoted 3 lines

And the standards have no idea how a resource limit hit for an fs would be reported, nor how an app installer would check for it. Quota on the other hand is defined behaviour.

EDQUOT is POSIX, but afaik there is no POSIX standardized API for quota, is there? i.e. the reporting of the user hitting quota is defined, but

Quoted 3 lines

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.

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.

Quoted 6 lines · Alan Cox

Quoted 3 lines

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.

Quoted 4 lines

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.

(11/7/2011 6:30 AM), Lennart Poettering wrote:

If you want per-user limitation, RLIMIT is bad idea. RLIMIT is only inherited by fork. So, The api semantics clearly mismatch your usecase.

Instead, I suggest to implement new sysfs knob.

Quoted 4 lines · KOSAKI Motohiro

(11/7/2011 6:30 AM), Lennart Poettering wrote:

If you want per-user limitation, RLIMIT is bad idea. RLIMIT is only inherited by fork. So, The api semantics clearly mismatch your usecase.

Like RLIMIT_NPROC?

Quoted 2 lines

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.

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:

Quoted 2 lines · Davidlohr Bueso

mm/shmem.c +0 -0

@@ -1159,7 +1159,12 @@ shmem_write_begin(struct file *file, struct address_space *mapping,
 			struct page **pagep, void **fsdata)

mm/shmem.c shmem_write_begin(struct file *file, struct address_space *mapping, · line 1167

Quoted 3 lines

mm/shmem.c +3 -0

+	if (atomic_long_read(&user->shmem_bytes) + len > 
+	    rlimit(RLIMIT_TMPFSQUOTA))
+		return -ENOSPC;

Is this a per-process or per-user limit? If it's per-process, it doesn't really do much good, because a user can use multiple processes to over-run the limit (either intentionally or accidentally).

Quoted 3 lines

mm/shmem.c +0 -0

@@ -1169,10 +1174,12 @@ shmem_write_end(struct file *file, struct address_space *mapping,
 			struct page *page, void *fsdata)

mm/shmem.c shmem_write_end(struct file *file, struct address_space *mapping, · line 1182

Quoted 4 lines

mm/shmem.c +3 -0

+	if (pos + copied > inode->i_size) {
 		i_size_write(inode, pos + copied);
+		atomic_long_add(copied, &user->shmem_bytes);
+	}

If this is per-user, it's racy with shmem_write_begin() - two processes can hit the write_begin(), be under quota by (say) 1M, but by the time they both complete the user is 1M over the quota.

mm/shmem.c out: · line 1552

Quoted 3 lines

mm/shmem.c +2 -0

 @@ -1535,12 +1542,15 @@ static int shmem_unlink(struct inode *dir, struct dentry *dentry)
+	struct user_struct *user = current_user();
+	atomic_long_sub(inode->i_size, &user->shmem_bytes);

What happens here if user 'fred' creates a file on a tmpfs, and then logs out so he has no processes running, and then root does a 'find tmpfs -user fred -exec rm {} \;' to clean up? We just decremented root's quota, not fred's....