linux-kernel - Re: [PATCH] nextfd(2)

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: <4F78D0BA.9040709@zytor.com>
Date:	Sun, 01 Apr 2012 15:03:38 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
CC:	akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
	torvalds@...ux-foundation.org, drepper@...il.com,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] nextfd(2)

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.
>   Looking at /proc/self/fd requires opening directory
>   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.
> 

This is really the motivation for this... the real question is how much
functionality is actually available in the system without /proc mounted,
and in particular if this particular subcase is worth optimizing ...
after all, if someone is maliciously setting rlimit, we can just abort
(if someone can set an rlimit they can also force an abort) or revert to
the slow path.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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