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

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


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

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

>>> Anyway, a dirty hack to turn off FORTIFY_SOURCE on Fedora 8, without
>>> touching the Bacula source, is to specify the CFLAGS in the RPM spec
>>> file. See below patch to Scott's bacula-2.2.8-1.s

>>> rc.rpm spec file. It is
>>> a really bad idea to specify CFLAGS in the spec file, but I don't know
>>> any other way to do it without changing Bacula's configure script. I
>>> have tested on a x86_64 FC8 pv domU under Xen 3.1 Centos 5.1 dom0 on a
>>> dual-core Opteron.
>>>
>>> It would be nice if there were a --disable-fortify arg to the configure
>>> script that removed the FORTIFY_SOURCE flag from the default CFLAGS or
>>> set it to zero. That would make life easier for the packagers, while
>>> still not requiring massive changes to the Bacula source. :)
>>> Considering that Suse is now using FORTIFY_SOURCE=2, they  too could
>>> very well break Bacula when they move to glibc 2.7+. Centos might at
>>> some point run into this "feature" as well.
>>>       
>> The Bacula developers set the ./configure and Makefile up to build the source 
>> code the way we feel is the best. I am not too enthusiastic about adding a 
>> new option, because It is not really my way of doing things  to "forbid" 
>> certain options.  IMO it is the prerogative and responsibility of the person 
>> building Bacula to put whatever options he/she wants.  Since there *is* a 
>> workaround for this gcc bug, I prefer to leave it as is and spend time on 
>> adding new features.  However, were a patch submitted, I doubt it would be 
>> rejected :-)
>>
>> By the way, I do know how to fix the problem (proper casting), but just have 
>> not found the time to get back and modify the code.  In the process, I should 
>> be able to remove what I consider an ugly kludge added to make the Win32 
>> compiler work.
>>
>> Best regards,
>>
>> Kern
>>
>>     
>>> Please note that the patch also removes the cp of static-bacula-fd for
>>> fc8. This is because the static bacula-fd will not compile on Fedora 8
>>> with glibc 2.7-2, apparently due to a glibc bug. At least, I couldn't
>>> get it to compile.
>>>
>>> --- BEGIN_PATCH---------------
>>> --- bacula.spec 2008-01-27 09:39:18.000000000 -0500
>>> +++ new/bacula.spec     2008-02-08 15:43:54.000000000 -0500
>>> @@ -1203,6 +1203,14 @@
>>>  export LDFLAGS="${LDFLAGS} -L/usr/lib/termcap"
>>>  %endif
>>>
>>> +%if %{fc8} && %{x86_64}
>>> +export 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"
>>> +%endif
>>> +
>>> +%if %{fc8} && ! %{x86_64}
>>> +export CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=0 -fexceptions
>>> -fstack-protector --param=ssp-buffer-size=4 -march=i386 -mtune=generic
>>> -fno-strict-aliasing -fno-exceptions -fno-rtti"
>>> +%endif
>>> +
>>>  cwd=${PWD}
>>>  cd %{depkgs}
>>>  %if %{sqlite}
>>> @@ -1584,7 +1592,9 @@
>>>  cp -pr %{_rescuesrc}/autoconf $RPM_BUILD_ROOT%{sysconf_dir}/rescue/
>>>  cp -pr %{_rescuesrc}/knoppix $RPM_BUILD_ROOT%{sysconf_dir}/rescue/
>>>  touch $RPM_BUILD_ROOT%{sysconf_dir}/rescue/linux/cdrom/rpm_release
>>> +%if ! %{fc8}
>>>  cp -p src/filed/static-bacula-fd
>>> $RPM_BUILD_ROOT%{sysconf_dir}/rescue/linux/cdrom/bacula/bin/bacula-fd
>>> +%endif
>>>  rm -f src/filed/static-bacula-fd
>>>
>>>  # install bat since make doesn't at the moment
>>> --- END_PATCH-----------------
>>>
>>>       
>>>> Best regards,
>>>>
>>>> Kern
>>>>
>>>> On Tuesday 29 January 2008 00.02:45 Michael Lausch wrote:
>>>>         
>>>>> The error is due to the new (well ~ core 5) buffer overflow checking
>>>>> implemented by gcc and glibc. _FORTIFY_SOURCE=2  activates it. what
>>>>> happens can be read in detail at
>>>>> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html. but basically
>>>>> the error is a buffer overflow check in parse.c in the bacula library.
>>>>>
>>>>> In this file the following definition can be found:
>>>>> extern  CURES res_all;
>>>>> CURES is a type defined in the library with a size of, let's say 120
>>>>> bytes. the actual value is not important.
>>>>>
>>>>> In the bat module for example, the res_all variable is redefined as
>>>>> URES res_all;
>>>>> in bat_conf.cpp. URES is a type with, let's say, 250 bytes. The actual
>>>>> value is not important as long as it's larger then the size of the URES
>>>>> type defined in the library. The variable res_all_size is initialized to
>>>>> the size of the res_all variable, in my example to 250.
>>>>>
>>>>> In the init_resource() function in parse_conf.c is a call to
>>>>> memset(&res_all, 0, res_all_size);
>>>>> This call is replaced to a boundary checking memset() call as outlined
>>>>> by the example 2 in
>>>>> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html
>>>>> The 3rd parameter of the memset call, res_all_size, which is 250, is
>>>>> checked against the size of the CURES type (120) and the buffer overflow
>>>>> error is raised by the boundary check of the memset function.
>>>>>
>>>>>
>>>>> The solution is to allocate the res_all variable dynamically.
>>>>>
>>>>> My quick hack solution was to change the definition of CURES to
>>>>> union CURES {
>>>>>    MSGS  res_msgs;
>>>>>    RES hdr;
>>>>>    char _space_[1024];
>>>>> };
>>>>> This makes the size of the CURES union larger than all the other unions
>>>>> defined in the different bacula executables and the memset check
>>>>> succeeds. But as i said this is a hack and i used it only as a band aid
>>>>> to get a runnable system.
>>>>>
>>>>> The solution to disable boundary checking by using a D_FORTIFY_SOURCE=0
>>>>> definition in the compiler command line should not be done, because
>>>>> checking for errors in such a sensible application as a backup utility
>>>>> is always a good thing.
>>>>>           
>>>> -------------------------------------------------------------------------
>>>> 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 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 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.