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

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


On Saturday 16 February 2008 17.03:32 Scott Barninger wrote:
> On Mon, 2008-02-11 at 14:14 -0500, Josh Fisher wrote:
> > Scott Barninger wrote:
> > > On Sat, 2008-02-09 at 08:54 +0100, Kern Sibbald wrote:
> > >
> > > 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.
> >
> > Maybe not. The %configure macro defined in /usr/lib/rpm/redhat/macros
> > defines CFLAGS="${CFLAGS:-%optflags}" prior to the call to ./configure.
> > Thus, if CFLAGS is not already defined, then it sets CFLAGS to defaults
> > set by %optflags, which contains global CFLAGS flags plus
> > architecture-dependent (-mtune,-march, etc.) flags. If CFLAGS is already
> > defined when %configure is invoked, then it uses it as is and does not
> > pull in the %optflags value. Using the spec file from
> > bacula-2.2.8-1.src.rpm I got (on x86_64):
> >
> > CFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
> > -fno-strict-aliasing -fno-exceptions -fno-rtti
> >
> > Using the spec file from bacula-2.2.8-2.src.rpm I get:
> >
> > CFLAGS =  -D_FORTIFY_SOURCE=0 -fno-strict-aliasing -fno-exceptions
> > -fno-rtti
> >
> > This is because the CFLAGS defaults are not pulled in by the %configure
> > macro due to explicitly setting CFLAGS in the spec file. This is why it
> > is a bad idea to set CFLAGS in the spec file. I don't think there is a
> > generic solution for the spec file, and Kern is correct in that it will
> > have to be up to the packager. I was able to turn FORTIFY_SOURCE off by
> > copying the %__global_cflags definition from /usr/lib/rpm/redhat/macros
> > to my ~.rpmmacros file and changing the -DFORTIFY_SOURCE flag there,
> > resulting in the folowing line in my ~/.rpmmacros file:
> >
> > %__global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=0 -fexceptions
> > -fstack-protector --param=ssp-buffer-size=4
> >
> > After adding the above line to ~/.rpmmacros and going back to the spec
> > file from bacula-2.2.8-1.src.rpm (ie that does not set CFLAGS in the
> > spec file), I get:
> >
> > CFLAGS = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=0 -fexceptions
> > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
> > -fno-strict-aliasing -fno-exceptions -fno-rtti


Gads, that certainly is not the Bacula way of building, and who know what 
kinds of problems all those options will create.  One thing is sure, 
exceptions should *not* be turned on. 

 I'm not very enthusiastic about the other options, but they might be OK.  
Please note that the following *are* Bacula's 
options: "-fno-strict-aliasing -fno-exceptions -fno-rtti"  and one of them is 
just the inverse of the -fexceptions so who knows what is being generated!

> >
> > which is correct for the x86_64 platform I am building on.
> >
> > So, I think your first RPM source, bacula-2.2.8-1.src.rpm, is actually
> > the correct one, and the second version does not set CFLAGS correctly
> > for x86_64. There doesn't seem to be any architecture-independent way of
> > turning off FORTIFY_SOURCE from the spec file, or from the configure
> > script for that matter.
> >
> > This is not ideal, and it would be nice if Fedora/RedHat provided some
> > means for turning off FORTIFY_SOURCE from the spec file, but it is not
> > too difficult to add a line to the ~/.rpmmacros file. I think we can
> > live with that for now.
> >
> > Regards,
> >
> > Josh
>
> There may be another way around this. All of the above is only true when
> you invoke the %configure macro. Kern, correct me if I'm wrong, but if I
> replaced %configure with ./configure then wouldn't the configure script
> set up all the compiler flags as intended by bacula?

Yes, it should do as you expect, providing the rpm has not modified the 
environment variables, and providing they don't count on any of their 
particular options being set.  You might try it since it would be a much 
simpler solution.


-------------------------------------------------------------------------
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.