Re: [RFC PATCH] tmpfs: support user quotas

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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

Direct render objects (like shared memory objects) are backed by shmfs,
so if you impose random limits on the shmfs you'll get weird graphics
happenings. You use a *lot* of shmfs objects when you are running 3D
gaming, enormous amounts for all your textures and the like.

The DRM case means you can't set tight limits on shmfs and expect to play
Warcraft.

> 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

Oh I do. That would actually do something abut temporary file handling
which is a much much bigger issue than a DoS when people get it wrong.
It's a bit of Unix history that wants sorting out more than /usr
and /bin...

> /tmp and on /dev/shm. Despite that without some ugly namespace hackery

Only if they were all logged in

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

Don't forget there have been pam modules for doing per user /tmp/ for
years and years.

> Resource limits are exactly the API that makes sense here, because:

No because they are inherited process things and the exhaustion behaviour
is not standards defined. Christoph is right that this should be
implemnted via quota.

It might well be that your quota implementation is handled by a mount
option (sysfs just makes it more complex) and that

	mount blah -oquotaallusers=16G 

is how you set it up, but doing it via quota interfaces makes all sorts
of crap just work including warning users about quota limits.

Alan