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]

Message-ID: <20111107143010.GA3630@tango.0pointer.de>
Date:	Mon, 7 Nov 2011 15:30:10 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

On Mon, 07.11.11 13:58, Alan Cox (alan@...rguk.ukuu.org.uk) 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

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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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/