linux-kernel - Re: [RFC PATCH] tmpfs: support user quotas

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Nov 2011 23:01:35 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Lennart Poettering <mzxreary@...inter.de>
Cc:	Davidlohr Bueso <dave@....org>,
	Christoph Hellwig <hch@...radead.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	Kay Sievers <kay.sievers@...y.org>
Subject: Re: [RFC PATCH] tmpfs: support user quotas

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