am I allowed to override -D_FORTIFY_SOURCE=2 with -D_FORTIFY_SOURCE=0 for
my Zarafa package until either upstream fixed their code or until glibc is
making their protection check more flexible? I already read the Packaging
Guidelines, but they still leave open, what's happening, if I am doing it.
Our glibc > 2.14.90-8 contains a commit which adds range checking to FD_SET
and friends (http://sourceware.org/ml/glibc-cvs/2011-q3/msg00235.html
also found http://sourceware.org/bugzilla/show_bug.cgi?id=10352
and it's funny to see that Ulrich Drepper implemented what he didn't even
want to revisit in the bug report.
Finally, that FD_SET range checking causes Zarafa to segfault once it has
been built using glibc > 2.14.90-8 (which is Fedora 16+), __fdelt_chk() is
simply called as they use more than 1024 file descriptors.
contains whole story, I
sat down with Jan Kratochvil to identify the cause, communicated with the
Zarafa developers and with Jeff Law, our glibc package maintainer. And also
with Adam Jackson on IRC.
The feedback from the Zarafa developers was, that the check in glibc is a
good idea, but based on wrong assumptions. Together with the upcoming mass-
rebuild they think, we could have a lot of fun, because many software will
possibly run into __fdelt_chk(). I hope, I summarized them correct.
I'm not a developer/programmer, but from what I get > 1024 file descriptors
work under certain conditions and if correctly developed and thus the glibc
range check is maybe not flexible enough.
From the BSD 4.2 FD_SET man page (http://www.manpagez.com/man/2/FD_SET/
[...] The default size FD_SETSIZE (currently 1024) is somewhat
than the current kernel limit to the number of open files. However, in
order to accommodate programs which might potentially use a larger number
of open files with select, it is possible to increase this size within a
program by providing a larger definition of FD_SETSIZE before the
inclusion of <sys/types.h>. [...]
I might be wrong, but that is what Zarafa is doing and what glibc code is
not covering. Maybe somebody with proper knowledge can have a look to this
once more? Thanks!
# Segmentation faults with glibc > 2.14.90-8, see RHBZ #760888
Above is the snippet, that I would like to introduce into the spec file for
the time being and to get the software up and running again. As you can see
in the bug report, there are users running into this issue.