[Fedora-packaging] Override with -D_FORTIFY_SOURCE=0 as workaround allowed?

[Robert Scheck]

Hello folks,

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). I
also found http://sourceware.org/bugzilla/show_bug.cgi?id=10352 meanwhile,
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.

https://bugzilla.redhat.com/show_bug.cgi?id=760888 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 smaller
> 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
> export CXXFLAGS="${RPM_OPT_FLAGS/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=0}"

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.


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120110/9cd01b04/attachment.sig>