[lkml]   [2011]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] tmpfs: support user quotas
(11/7/2011 6:30 AM), Lennart Poettering wrote:
> On Mon, 07.11.11 13:58, Alan Cox ( 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

Ok, seems fair.

> 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

Why? Is there any benefit this?

> 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.

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.

Thank you.

 \ /
  Last update: 2011-11-07 23:17    [W:0.086 / U:1.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site