From: "H. Peter Anvin" <hpa@zytor.com>
To: Theodore Tso <tytso@mit.edu>, "H. Peter Anvin" <hpa@zytor.com>,
Christoph Hellwig <hch@infradead.org>,
Ulrich Drepper <drepper@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: If not readdir() then what?
Date: Sun, 08 Apr 2007 12:13:35 -0700 [thread overview]
Message-ID: <46193EDF.3000303@zytor.com> (raw)
In-Reply-To: <20070408184735.GC29180@thunk.org>
Theodore Tso wrote:
>
> 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.)
>
If you want to have a large cookies, you could have glibc allocate a
memory block to store it, and have glibc responsible for keeping track
of it. As far as I know, off_t can hold a pointer on all our
implementations (only 32-bit machines have 32-bit off_t as an option;
Alpha *might* be an exception but I don't think so.)
> 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.
Readdir/telldir are much, much, more fundamental than that. We're
talking interfaces which have been standardized for longer than Linux
itself has existed.
-hpa
next prev parent reply other threads:[~2007-04-08 19:14 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-07 16:57 If not readdir() then what? Ulrich Drepper
2007-04-07 20:36 ` Theodore Tso
2007-04-07 23:30 ` Christoph Hellwig
2007-04-08 18:11 ` H. Peter Anvin
2007-04-08 18:41 ` Jörn Engel
2007-04-08 19:19 ` Theodore Tso
2007-04-08 19:26 ` Ulrich Drepper
2007-04-08 19:28 ` H. Peter Anvin
2007-04-08 19:40 ` Ulrich Drepper
2007-04-09 1:44 ` Theodore Tso
2007-04-09 11:09 ` Jörn Engel
2007-04-09 12:29 ` Trond Myklebust
2007-04-09 12:31 ` Trond Myklebust
2007-04-09 13:19 ` Theodore Tso
2007-04-09 14:03 ` Trond Myklebust
2007-04-09 16:34 ` Jan Engelhardt
2007-04-09 17:00 ` Trond Myklebust
2007-04-10 13:56 ` Theodore Tso
2007-04-10 14:10 ` Ulrich Drepper
2007-04-10 15:48 ` H. Peter Anvin
2007-04-10 16:42 ` Ulrich Drepper
2007-04-10 14:37 ` Trond Myklebust
2007-04-10 15:54 ` Jan Engelhardt
2007-04-10 16:18 ` H. Peter Anvin
2007-04-10 16:25 ` Valdis.Kletnieks
2007-04-10 21:12 ` Neil Brown
2007-04-10 21:16 ` H. Peter Anvin
2007-04-10 21:43 ` Neil Brown
2007-04-10 21:18 ` Trond Myklebust
2007-04-10 21:37 ` Neil Brown
2007-04-10 21:57 ` Bob Copeland
2007-04-10 21:59 ` Trond Myklebust
2007-04-10 22:33 ` Neil Brown
2007-04-11 0:22 ` Trond Myklebust
2007-04-11 1:45 ` Bernd Eckenfels
2007-04-10 21:46 ` Alan Cox
2007-04-10 21:26 ` Neil Brown
2007-04-09 12:46 ` Andreas Schwab
2007-04-10 21:15 ` Neil Brown
2007-04-11 13:57 ` Jan Engelhardt
2007-04-11 14:42 ` Theodore Tso
2007-04-11 22:32 ` Neil Brown
2007-04-11 22:06 ` David Lang
2007-04-11 23:23 ` H. Peter Anvin
2007-04-11 23:33 ` Jörn Engel
2007-04-12 0:00 ` Neil Brown
2007-04-11 23:22 ` Theodore Tso
2007-04-12 1:46 ` Neil Brown
2007-04-12 2:37 ` Jörn Engel
2007-04-12 5:57 ` Neil Brown
2007-04-12 9:33 ` Jörn Engel
2007-04-12 12:21 ` Theodore Tso
2007-04-12 17:18 ` J. Bruce Fields
2007-04-12 17:35 ` H. Peter Anvin
2007-04-16 3:05 ` Theodore Tso
2007-04-16 5:47 ` Neil Brown
2007-04-16 10:39 ` Theodore Tso
2007-04-16 6:18 ` Neil Brown
2007-04-16 11:07 ` Theodore Tso
2007-04-16 23:24 ` Neil Brown
2007-04-08 18:47 ` Theodore Tso
2007-04-08 19:13 ` H. Peter Anvin [this message]
2007-04-08 18:50 ` Ulrich Drepper
2007-04-07 23:44 ` Jan Engelhardt
2007-04-08 20:36 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46193EDF.3000303@zytor.com \
--to=hpa@zytor.com \
--cc=drepper@gmail.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.