linux-kernel - Re: If not readdir() then what?

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:	Sun, 8 Apr 2007 14:47:35 -0400
From:	Theodore Tso <tytso@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Ulrich Drepper <drepper@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: If not readdir() then what?

On Sun, Apr 08, 2007 at 11:11:20AM -0700, H. Peter Anvin wrote:
> Christoph Hellwig wrote:
> >On Sat, Apr 07, 2007 at 04:36:33PM -0400, Theodore Tso wrote:
> >>this functionality, and it is highly questionable how useful it is,
> >>anyway.  If you use telldir/seekdir and keep the cookie for a long
> >>time, even the POSIX-provided guarantees about files that are created
> >>and deleted between the telldir() and seekdir() points in time makes
> >>its utility highly dubious.
> >
> >It's not going to solve anything at all.  We can't stop supporting
> >functionality that has been there forever. 
> 
> Well, the question is if you can keep the seekdir/telldir cookie around 
> as a pointer -- preferrably in userspace, of course.  You would 
> presumably garbage-collect them on closedir() -- there is no other point 
> at which you could.
> 
> I personally suspect that hch is right -- this stuff has been there 
> since time immemorial and it'll be hard or impossible to deprecate it.

You could, but then you're succeptible to a memory allocation attack.
If you have an arbitrarily large directory (say, one with multiple
millions of entries), and the attacker program calls seekdir() after
every single readdir() call, you would then force the kernel to
allocate and then pin arbitrarily large amounts of memory, which as
you point out, as currently specified by the POSIX specification, you
are not allowed to release until closedir().

This could be done in userspace, by forcing glibc to readdir() the
entire directory into memory, at which point seekdir()/telldir() will
work just fine.  But for a really big directory, this could consume a
huge amount of space. 

If we had the 64-byte telldir cookie that I had proposed, then in
userspace we could simply associate that 64-byte telldir cookie with a
small 32-bit integer, either in memory, or in some berkdb or tdb
interface, at least until the use of telldir/seekdir had actually
disappeared.  (Which probably wouldn't take that long; I really doubt
there are that many users of it out there, so it's probably OK if they
suffer a performance penality if they use this really wretched and
horrible interface.)

I'll also note, by the way, that there are those who have been much
more cavalier with breaking the wireless interface or the udev/sys
interface after one year.  Not that I would agree with that, but over
some deprecation period measured in years, I think it is possible to
nuke what was a horribly misguided interface that should have never
existed.  Whoever invented it really should receive the brown paper
award for one of the worst design decisions of all time.

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