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]

Message-ID: <a36005b50704081150i5a457963w2ab5928f873eeabf@mail.gmail.com>
Date:	Sun, 8 Apr 2007 11:50:27 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Christoph Hellwig" <hch@...radead.org>,
	"Theodore Tso" <tytso@....edu>,
	"Ulrich Drepper" <drepper@...il.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: If not readdir() then what?

On 4/7/07, Christoph Hellwig <hch@...radead.org> wrote:
> It's not going to solve anything at all.  We can't stop supporting
> functionality that has been there forever.

Not necessarily.

One problem here is that the interface for using readdir() with and
without telldir()/seekdir() is the same.  A second problem is that the
functionality is universally required.  Both of these problems can be
addressed.

For the second problem, I certainly could imagine that making the
functionality to to use seekdir()/telldir() optional.  It might be
hard in POSIX but this does not mean anything about implementations.
Implementations just have to provide a way to allow these functions to
be used.  It does not mean it always and everywhere has to work.  What
this means is that if, for instance, a filesystem would be (for now)
be able to have a mount option to not allow seekdir()/telldir() the
system still can conform to POSIX.  At the same time we can gather
information as to whether seekdir()/telldir() are really needed.  I
personally think the number of apps which depend on this functionality
is miniscule.

Using a mount option isn't the nicest solution, though.  If a
filesystem can support seekdir()/telldir() the better solution from
the userlevel API POV would be to provide a better, alternative
interface.  Maybe an alternative opendir() call (opendir2?) which
takes a second parameter as to whether seeking is needed or not.  Then
this opendir2() function can use a new getdents() syscall and return
the entries.  The difference would be that if the user wants to use
seekdir()/telldir() the userlevel code would cache the old results and
the seekdir()/telldir() handling would be entirely at userlevel.

It's not a good idea to make this the default behavior for the old
opendir() since the vast majority of the current users don't want to
seek and therefore the caching would significantly impact the
performance.  With the extra argument saying when caching is needed
this is no problem anymore.  Over time people would migrate off of
opendir() and towards opendir2() (with some "careful" encouragement)
and the whole problem will go away.

And the best: this is certainly a path I can see being viable for
POSIX.  But it requires that we have
a) established existing practice
b) shown the impact is really low

So, I think it would be great to get started writing this new getdents
call.  Yes, for now it means maintaining two separate versions.  If
all goes well those filsystems which feel a high burden can simply
stop supporting the old syscall or at least the seek functionality.
-
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/