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

Re: [Bacula-devel] "buffer overflow detected" error on fedora distributions.


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

Attachment: 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.