Re: [PATCH] nextfd(2)

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, drepper@gmail.com,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] nextfd(2)
Date: Mon, 2 Apr 2012 01:08:19 +0100	[thread overview]
Message-ID: <20120402010819.76d31790@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4F78D0BA.9040709@zytor.com>

On Sun, 01 Apr 2012 15:03:38 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 04/01/2012 05:57 AM, Alexey Dobriyan wrote:
> > 
> > * /proc/self/fd is unreliable:
> >   proc may be unconfigured or not mounted at expected place.

Equally someone could be ptracing your process and changing the answers.
Both are "do stupid stuff, get stupid answers" cases. Why do we care ???
Lots of other stuff breaks in this case so nobody will be doing it for
good reasons

> >   Looking at /proc/self/fd requires opening directory

Which is very efficient

> >   which may not be available due to malicious rlimit drop or ENOMEM situations.
> >   Not opening directory is equivalent to dumb close(2) loop except slower.

If I've rlimited you to no file handles then you already lost whichever
approach you use. Just abort. Trying to do clever stuff in security
sensitive situations via codepaths that inevitably don't get tested when
you've apparently got a malicious executor is dumb.

> (if someone can set an rlimit they can also force an abort) or revert to
> the slow path.

Or have set a CPU limit or memory limit or more.

Alan