diff options
author | Niels de Vos <ndevos@redhat.com> | 2014-03-27 20:34:44 +0100 |
---|---|---|
committer | Anand Avati <avati@redhat.com> | 2014-04-21 10:25:21 -0700 |
commit | 20e317011af7c0f075819bf0648b225f6dc42350 (patch) | |
tree | 35576dbeb6202d529e4a8c0a3ae8faa168299a59 /xlators/mgmt | |
parent | 2da51737c49f7917a974bdf9e6e566307583ad16 (diff) |
fuse: prevent READDIR(P) from writing to much data to /dev/fuse
In an environment with mixed architectures (32-bit servers, 64-bit
client), it is possible that the on-wire Reply on a READDIR(P) procedure
contains more direntries than the client can fit in the maximum size
that the fuse-request indicated.
A direntry is a dynamically sized structure, because the structure
contains the name of the entry. The client sends a maximum size in the
READDIR(P) Call to the server, and the server uses this size to limit
the number of direntries to return. In case the server can pack more
direntries in the requested maximum size (due to alignment differences
between the architectures), it can happen that the client unpacks the
list of direntries into a buffer that exceeds the maximum size that was
given in the initial fuse-request.
This change introduces a check for the maximum requested size of the
fuse-response in fuse_readdir_cbk() and fuse_readdirp_cbk(). When the
conversion from gluster-direntries to the fuse-direntry format takes
place, the maximum size is checked, and the 'extra' direntries are
discarded. The next readdir()/getdents() that is done, will fetch the
just discarded direntries again.
In addition to this bugfix, some extra logging in send_fuse_iov() and
send_fuse_data() has been added to help diagnosing similar issues.
Change-Id: If2eecfcdf9c248f3820035601446d2c89ff9d1a1
BUG: 1074023
Signed-off-by: Niels de Vos <ndevos@redhat.com>
Reviewed-on: http://review.gluster.org/7278
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Xavier Hernandez <xhernandez@datalab.es>
Reviewed-by: Anand Avati <avati@redhat.com>
Diffstat (limited to 'xlators/mgmt')
0 files changed, 0 insertions, 0 deletions