On Sat, 2008-02-09 at 13:55 +0100, Kern Sibbald wrote: > On Saturday 09 February 2008 13.26:25 Scott Barninger wrote: > > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote: > > > On Friday 08 February 2008 23.16:43 Josh Fisher wrote: > > > > Kern Sibbald wrote: > > > > > Please Note the following quote from the documentation on the > > > > > implementation of FORTIFY_SOURCE=2 > > > > > > > > > > With -D_FORTIFY_SOURCE=2 some more checking is added, but > > > > > some conforming programs might fail. > > > > > > > > > > Bacula is a conforming program (i.e. there is no buffer overrun at > > > > > that point). > > > > > > > > I agree. The checking is too simplistic (for performance reasons I > > > > suppose) and so hits too many false positives. Putting > > > > -DFORTIFY_SOURCE=2 into the default CFLAGS was a big mistake, because > > > > it will break perfectly safe code, like Bacula and probably many > > > > others. I could see it as a compile-time error, maybe, but not a > > > > run-time error. > > > > > > I can understand that they (rpm guys) would make FORTIFY_SOURCE=2 a > > > default, even though like you it is not something I would do, because > > > according to their own documentation (see above) it doesn't always work, > > > but where I have a real problem is that they apparently don't make it > > > simple to remove the FORTIFY_SOURCE. > > > > Wouldn't the following work, without modifying any other settings? > > > > export CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=0" > > > > The string would then first set it to 2 and last reset to zero. And it > > works for all platforms. > > The above will work correctly within Bacula's standard ./configure, make > environment, but I am not sure about the low level details of building rpms. > You would probably have to try it to see if it works. If I am not mistaken, > the rpm code explicitly modifies all the command lines that Bacula generates, > so if they do the modification after we export CFLAGS, the above is not > likely to work. > I am assuming that you already have some workaround for building rpms (i.e. a > way to disable the FORTIFY_SOURCE, and so I am not at the moment considering > this a critical problem. If this is not the case, please let me know. >
I've a patch ready for the spec file. Basically the _FORTIFY_SOURCE=2 definition, and some other optimisation and code security stuff is set in the __global_cflags RPM define. This definition is set in the ~/.rpmmacros or in the /usr/lib/rpm/redhat/macros file. The patch just overrides the standard __global_cflags defintion with a definition without _FORTIFY_SOURCE, depending on the broken_rh definition.
--- bacula.spec 2008-01-29 21:38:28.518916775 +0100
+++ bacula.spec.nofort 2008-02-09 14:14:40.502303517 +0100
@@ -316,6 +316,10 @@
BuildRequires: qwt-devel >= 5.0
%endif
+%if %{broken_rh}
+%__global_cflags -O2 -g -pipe -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
+%endif
+
%if %{rh7}
BuildRequires: libtermcap-devel
BuildRequires: glibc-devel >= 2.2
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
