gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gluster-devel] glfs_readdir_r is painful


From: Eric Blake
Subject: [Gluster-devel] glfs_readdir_r is painful
Date: Wed, 30 Oct 2013 11:18:29 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

I'm trying to use glusterfs-api, but ran into some questions on usage
(currently targetting Fedora 19's glusterfs-api-devel-3.4.1-1.fc19.x86_64).

Why is there no glfs_readdir?  POSIX readdir_r() is broken by design; it
assumes that the caller is providing a large enough buffer, but does not
take a buffer size as a parameter, so it is very easy to trigger buffer
overflow bugs, since struct dirent contains only a variable-length
d_name member.

Read this for more details about how hard it is to use readdir_r
properly: http://womble.decadent.org.uk/readdir_r-advisory.html

Read this for proof that POSIX is considering ditching readdir_r
altogether and merely require sane thread-safety requirements on
readdir() (since at least that way there are no buffer overflow
attacks): http://austingroupbugs.net/view.php?id=696

The only safe way to use readdir_r is to know the maximum d_name that
can possibly be returned, but there is no glfs_fpathconf() for
determining that information.  Your example usage of glfs_readdir_r()
suggests that 512 bytes is large enough:
https://forge.gluster.org/glusterfs-core/glusterfs/blobs/f44ada6cd9bcc5ab98ca66bedde4fe23dd1c3f05/api/examples/glfsxmp.c
but I don't know if that is true.  You _do_ have the advantage that
since every brick backing a glusterfs volume is using an xfs file
system, then you only have to worry about the NAME_MAX of xfs - but I
don't know that value off the top of my head.  Can you please let me
know how big I should make my struct dirent to avoid buffer overflow,
and properly document this in <glusterfs/api/glfs.h>?  Furthermore, can
you please provide a much saner glfs_readdir() so I don't have to worry
about contortions of using a broken-by-design function?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]