Re: [RFC PATCH] tmpfs: support user quotas

[Glauber Costa]

On 11/07/2011 08:53 PM, Alan Cox wrote:
> > 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 ?

We are trying to implement an indirect limit on slab objects in the 
memory controller.
Our specific use case is to control the number of dentries currently 
pinned in some given physical filesystem. If you can't allocate a dentry 
from the dentry cache, you can also not DoS a system - in our case, a 
container.

Maybe this will also solve your problems?

> > 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@xxxxxxxxxx  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@xxxxxxxxx";>  email@xxxxxxxxx</a>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/