[Bug libc/14] Bug (+fix) in readdir() due to getdents()

["jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #7 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-18 19:51:29 UTC ---
I do not believe there is a glibc bug here.

* The bug report quotes a manpage for the readdir system call as saying that
d_off refers to the current dirent rather than the next dirent.  That is
correct, but irrelevant.  The readdir system call is a backwards compatibility
one using a very old version of the dirent structure.  With the getdents and
getdents64 syscalls, different structures are used, and in those structures the
semantics are that d_off refers to the next dirent, as you will see if you
refer to the kernel sources or the getdents manpage.  The getdents64 syscalls
is the relevant one here.

* The bug report claims there is an assumption that d_off contains a byte
offset.  Actually, there is no such assumption.  The only requirement is that
the kernel does not use -1 as an offset.  Otherwise, the offsets are used as
opaque values, stored, copied, converted to the userspace type (with the result
only compared for equality, not used for arithmetic) and used as an argument
for __lseek64.  Using as an argument for __lseek64 (with SEEK_SET) is not using
the value as a byte offset; it's up to each filesystem in the kernel to
implement seeking on directories correctly so that it works with the opaque
d_off values provided by the kernel.  Some filesystems may use byte offsets and
some use other values involving a more complicated implementation of that seek
operation in the kernel.

* Various different filesystems have been used for automounting (e.g. autofs /
autofs4) and this report is not specific about exactly what filesystem, with
what kernel version, is used in the problem situations.  (Kernels before 2.6.0
are in any case not in practice relevant to current glibc, although some
support code for them has yet to be removed.)  But if a filesystem did not
handle seeking with values provided in d_off, that would be a bug in the
filesystem.

* It is certainly not correct to seek with byte offsets computed by glibc,
since offsets for seeking in a directory are the same sort of opaque cookie
provided in d_off and only those values may be passed to the kernel as a
position to which to seek.  So the patch here cannot be correct.

* Finally, there is a concern about the conversion of d_off from 64-bit to
32-bit.  It's true that some applications may not use this value (used for
telldir/seekdir), but the same applies to any other value returned by the
kernel (inode numbers in particular); glibc cannot know what values the
application wants and so must return EOVERFLOW if any value from the kernel
cannot be represented in the userspace type.  The way for applications to avoid
this is to be built with _FILE_OFFSET_BITS=64 so that the 64-bit interfaces are
used, and this is the normal practice nowadays for most applications given the
desire to support files over 2GB on 32-bit systems.

Regarding the other issues described with the source code, note that nbytes is
not provided by the user of glibc since getdents is an internal-only interface.
 There may well be issues there, but on any given system they would either be
latent or appear every time the relevant code in getdents is executed, so it
seems unlikely they affect any current system.  In any case, please always
avoid mixing different issues in a single bug; file separate issues for these
separate problems if you think they are still present.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.