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:	Tue, 8 Nov 2011 01:25:20 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Kay Sievers <kay.sievers@...y.org>, 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
Subject: Re: [RFC PATCH] tmpfs: support user quotas

On Mon, 07.11.11 23:43, Alan Cox (alan@...rguk.ukuu.org.uk) wrote:

> 
> On Tue, 8 Nov 2011 00:07:12 +0100
> Lennart Poettering <mzxreary@...inter.de> wrote:
> 
> > On Mon, 07.11.11 22:53, Alan Cox (alan@...rguk.ukuu.org.uk) wrote:
> > 
> > > Per user would be quota, per process would be rlimit. Quite simple
> > > really, nice standard interfaces we've had for years. Various systems
> > 
> > Uh, have you ever really looked at resource limits? Some of them are
> > per-user, not per-process, i.e. RLIMIT_NPROC. And this would just be
> > another one.
> 
> NPROC is a bit of an oddity.

And half of the other resource limits are "oddities" too?
For  example RLIMIT_SIGPENDING is per-user and so is RLIMIT_MSGQUEUE,
and others too.

> And the standards have no idea how a resource limit hit for an fs would
> be reported, nor how an app installer would check for it. Quota on the
> other hand is defined behaviour.

EDQUOT is POSIX, but afaik there is no POSIX standardized API for quota,
is there? i.e. the reporting of the user hitting quota is defined, but
how to set the quota is left open. Which is nice, since it gives us the
flexibility to use resource limits here, since they so nicely apply to
the problem.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ