devil-linux-develop Mailing List for Devil-Linux (Page 39)

Bruce Smith wrote:
> I have DL running with the mods for /etc/ in a UnionFS.
> 
> There is an expanded /etc on the CD, the mods in /shm, joined to the
> real /etc directory.
> 
> One odd thing I've noticed.  The mods directory contains some files that
> have not been changed (like /etc/services and a few others).  The dates
> are 1980, and 'diff' shows they are exactly the same as the file on the
> CD, but the files are in the mods directory.  Any clue why?

Are you sure they weren't put there when you loaded the mods dir?

Dick

I have DL running with the mods for /etc/ in a UnionFS.

There is an expanded /etc on the CD, the mods in /shm, joined to the
real /etc directory.

One odd thing I've noticed.  The mods directory contains some files that
have not been changed (like /etc/services and a few others).  The dates
are 1980, and 'diff' shows they are exactly the same as the file on the
CD, but the files are in the mods directory.  Any clue why?

 - BS

Quoting Bruce Smith <br...@ar...>:

>
>>> Since UnionFS is already working in DL, I want to first get this working
>>> with unionfs and prove the concept that it will function as planned.
>>>
>>> Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
>>> Since they function similar then it should be easy to switch between
>>> UnionFS and aufs.  Right???
>>>
>>> Maybe we could make a menuconfig option to select which FS to use.
>>>
>>
>> Sounds like a good plan to me.
>>
>
> I've proved the concept.  I have a working ISO that runs with UnionFS
> mounted /etc.
>
> It boots with blank media.  save-config saves only the changes.  Changes
> load next boot, etc.
>
> There is more stuff to do.  I haven't started working on the automated
> upgrade to a new version yet.  And there is probably some code cleanup
> to do.
>
> Should I check in what I've done so far?  Or should I wait until the
> upgrade process is working?

I'd say wait,  since nobody will really be able to use it until then.

> Since this is such a major change, should I increase the version number
> from 1.3.4 to 1.3.5 (or something) when I check in the changes?  If so,
> remind me where to change the version?

yes please
scripts/config/version or something like that

> BTW, I have a busy weekend, so I may not get a chance to work on it
> again until next week.

Yeah same here, I'm actually at work right now upgrading systems....


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

>> Since UnionFS is already working in DL, I want to first get this working
>> with unionfs and prove the concept that it will function as planned.
>>
>> Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
>> Since they function similar then it should be easy to switch between
>> UnionFS and aufs.  Right???
>>
>> Maybe we could make a menuconfig option to select which FS to use.
>>     
>
> Sounds like a good plan to me.
>   

I've proved the concept.  I have a working ISO that runs with UnionFS 
mounted /etc.

It boots with blank media.  save-config saves only the changes.  Changes 
load next boot, etc.

There is more stuff to do.  I haven't started working on the automated 
upgrade to a new version yet.  And there is probably some code cleanup 
to do.

Should I check in what I've done so far?  Or should I wait until the 
upgrade process is working?

Since this is such a major change, should I increase the version number 
from 1.3.4 to 1.3.5 (or something) when I check in the changes?  If so, 
remind me where to change the version?

BTW, I have a busy weekend, so I may not get a chance to work on it 
again until next week.

 - BS

> > Is the fact that aufs is only in cvs, no tarballs available, going to be
> > a problem?
> 
> The is a benefit and downside.
> Benefit: We would always get the latest code.
> Downside: We would always get the latest code.
> 
> If he's currently working on something and about half of it is checked  
> in, we get code which won't work.

Hopefully that won't be a problem.  Quote from the web site:

"Usually I am updating CVS tree on every Monday.
 I always try putting the stable version in CVS,"

> > One nice thing is it's primarily a kernel module, and kernel patches may
> > not be necessary.  There are some optional kernel patches, which may be
> > required depending on what kernel options are selected.  I haven't
> > checked it against our kernel options yet.
> 
> This may be a good thing.

Yes, there is less to go wrong if there aren't any kernel patches.

 - BS

Quoting Bruce Smith <bw...@ar...>:

>> > Since UnionFS is already working in DL, I want to first get this working
>> > with unionfs and prove the concept that it will function as planned.
>> >
>> > Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
>> > Since they function similar then it should be easy to switch between
>> > UnionFS and aufs.  Right???
>> >
>> > Maybe we could make a menuconfig option to select which FS to use.
>>
>> Sounds like a good plan to me.
>
> Is the fact that aufs is only in cvs, no tarballs available, going to be
> a problem?

The is a benefit and downside.
Benefit: We would always get the latest code.
Downside: We would always get the latest code.

If he's currently working on something and about half of it is checked  
in, we get code which won't work.

> It's fairly simple to check out aufs from cvs and make our own tarball.
> I tried it yesterday, and the whole thing is only 1.8M.
>
> ...../aufs.wcvs$  du -sh .
> 1.8M    .
>
> One nice thing is it's primarily a kernel module, and kernel patches may
> not be necessary.  There are some optional kernel patches, which may be
> required depending on what kernel options are selected.  I haven't
> checked it against our kernel options yet.

This may be a good thing.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> > Since UnionFS is already working in DL, I want to first get this working
> > with unionfs and prove the concept that it will function as planned.
> >
> > Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
> > Since they function similar then it should be easy to switch between
> > UnionFS and aufs.  Right???
> >
> > Maybe we could make a menuconfig option to select which FS to use.
> 
> Sounds like a good plan to me.

Is the fact that aufs is only in cvs, no tarballs available, going to be
a problem?

It's fairly simple to check out aufs from cvs and make our own tarball.
I tried it yesterday, and the whole thing is only 1.8M.

...../aufs.wcvs$  du -sh .
1.8M    .

One nice thing is it's primarily a kernel module, and kernel patches may
not be necessary.  There are some optional kernel patches, which may be
required depending on what kernel options are selected.  I haven't
checked it against our kernel options yet.

 - BS

Quoting Bruce Smith <br...@ar...>:

>> > I don't know what the difference is. Aufs is not in DL right now.
>> > If aufs is really more stable and maybe better maintained, then we
>> > should go for that one.
>>
>> I don't know either.  The aufs people understandably advocate their offering
>> enthusiastically. See below.
>
> I haven't tried aufs, but it appears to function similar to unionfs?
>
> If so, here is my plan (feel free to shoot holes in it):
>
> Since UnionFS is already working in DL, I want to first get this working
> with unionfs and prove the concept that it will function as planned.
>
> Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
> Since they function similar then it should be easy to switch between
> UnionFS and aufs.  Right???
>
> Maybe we could make a menuconfig option to select which FS to use.

Sounds like a good plan to me.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> > I don't know what the difference is. Aufs is not in DL right now.
> > If aufs is really more stable and maybe better maintained, then we  
> > should go for that one.
> 
> I don't know either.  The aufs people understandably advocate their offering 
> enthusiastically. See below.

I haven't tried aufs, but it appears to function similar to unionfs?

If so, here is my plan (feel free to shoot holes in it):

Since UnionFS is already working in DL, I want to first get this working
with unionfs and prove the concept that it will function as planned.

Once we've proved it works with UnionFS, we can [try to] add aufs to DL.
Since they function similar then it should be easy to switch between
UnionFS and aufs.  Right???  

Maybe we could make a menuconfig option to select which FS to use.

 - BS

> Could it be got from Debian?

Maybe  http://packages.debian.org/sid/aufs-source  ?

 - BS

Bruce Smith wrote:
> [moving this thread to the develop list] 
> 
> I went to the aufs web site and I can't even find a tarball to download.
> The only way I can find to download the source is to check out from cvs.
> Does anyone know of a easier way to download aufs?
> 
> UnionFS has tarballs for all the latest kernels, including the RC
> kernels.  That method would much easier to maintain in DL.

I found this from 22-Mar-08:

 > > Abrao_Ferreira:
 > >>     Where i can download a package of au-FS project? The last version =
 > >> package with extension [.tar.gz] or [.tar.bz2]=20
 > >>     I have a link but this give me many files. I need only the source
 > >> in
 > >> =
 > >> a package to compile.=20
 > >
 > > I don't create a tarball.
 > > If you read http://aufs.sf.net, you would know you should get the source
 > > files via CVS.
 > >
 > >
 > > Junjiro Okajima

So be it!

Could it be got from Debian?

Dick

[moving this thread to the develop list] 

I went to the aufs web site and I can't even find a tarball to download.
The only way I can find to download the source is to check out from cvs.
Does anyone know of a easier way to download aufs?

UnionFS has tarballs for all the latest kernels, including the RC
kernels.  That method would much easier to maintain in DL.

 - BS


> >>> both unionfs and aufs are std in Debian if you've got a deb desktop.
> >> What's the difference between unionfs & aufs?  Does DL have aufs?
> >> Which one should we use for this?
> > 
> > I don't know what the difference is. Aufs is not in DL right now.
> > If aufs is really more stable and maybe better maintained, then we  
> > should go for that one.
> 
> I don't know either.  The aufs people understandably advocate their offering 
> enthusiastically. See below.
> 
> However I use Debian sid amd64 and I've not had unionfs working for a long while 
> for one reason or another whereas aufs worked first time out of the box so I'm 
> favourably disposed towards it.
> 
> Aufs claim their offering is smaller lighter, more reliable and better featured. 
>   Since we're only going to use a basic part of the functionality I doubt it 
> will make much difference.
> 
> > We also need to choose wisely, so we don't have to wait for a patch  
> > for a new kernel for a couple of months.
> 
> unionfs says it is in Andrew Mortons patches but I think that's as near either 
> are to being included in the kernel.
> 
> Dick
> 
> Why to use AuFS instead of unionfs:
> -----------------------------------
> 
> I am an AuFS user for a long time and what I really appreciate
> (from the user's point of view) is the following:
> 
> # AuFS supports writable branch balancing. That means, you can setup several 
> partitions for writing and AuFS will split all new/modified files between them, 
> based on free disk space, existence of parent directory, randomly, or combinations.
> 
> 
> # AuFS supports huge amount of branches. I'm currently using hundreds of 
> branches without just a small slowdown (which is obvious).
> 
> 
> # AuFS provides a list of branches through /sys, which doesn't have the 
> limitation like /proc/mounts. For that reason, it works correctly even with 
> thousand of branches (while so much branches would break /proc/mounts at all).
> 
> 
> # AuFS implements 'rr' branch mode, it means 'really-readonly'. This is really 
> useful, particularly for ISO images or SquashFS filesystems as a brach, as AuFS 
> doesn't need to re-lookup those filesystems. (You know, a readonly branch 'ro' 
> can be modified from another place, eg. network, so there can occur a 'direct 
> branch access' even for read-only directories and AuFS handles it correctly.)
> 
> 
> # last, but not the least, AuFS is really stable in real world situations. I 
> used unionfs in the past, but my second name for it was 'NULL POINTER 
> DEREFERENCE'. I can see those errors still happening in latest unionfs as well, 
> last one I've found is from 27th of May 2008 ... BUG: unable to handle kernel 
> NULL pointer dereference. ... I have absolutely no idea what that means, but the 
> same errors keep appearing in unionfs for years. You won't see anything like 
> that in AuFS. Guess why knoppix and other projects switched to it :)
> 
>                                                             Tomas M
>                                                             slax.org

> >> > --- mysql	27 Mar 2008 14:27:03 -0000	1.23
> >> > +++ mysql	10 Apr 2008 14:00:51 -0000	1.24
> >> > @@ -56,7 +56,7 @@
> >> >  		rm $TMPDIR/usr/lib/*.la || exit 1
> >> >  		copy_docs $TMPDIR
> >> >  		rm -rf $TMPDIR/usr/mysql-test || exit 1
> >> > -		cp $TMPDIR/usr/share/mysql/my-small.cnf $ETCDIR/etc/my.cnf || exit 1
> >> > +		sed 's/^\[mysqld\] *$/&\nuser\t\t= mysql/'
> >> > $TMPDIR/usr/share/mysql/my-small.cnf > $ETCDIR/etc/my.cnf || exit 1
> >> >  		mkdir -p $CDDIR
> >> >  		copy_files $TMPDIR/usr $CDDIR || exit 1
> >> >  		rm -rf $TMPDIR || exit 1
> >> >
> >>
> >> Should we add this statement to the init script for mysql?
> >
> > You mean add the user line to my.cnf in the init.d script, instead of
> > giving them the default my.cnf with the user line already in there?
> 
> I was thinking about a check, if it's not in there then add it,  
> otherwise ignore.

Yeah, it's doable.  

I checked, and if you have 'user=' in my.cnf, and you supply "--user" on
the command line to start mysqld, it uses the one in my.cnf.

Again, I don't like mucking with someone's customized config file for
fear of breaking something else.  I'd rather post some kind of notice
that they need to add the line to their file if they are experiencing
the problem.

> >> This would help us with custom my.cnf files, but would prevent users
> >> from changing the username for mysql
> >
> > I hate to go mucking with someone's customized config files without
> > telling them.  (and we can't ask for confirmation, because we're trying
> > to make it boot correctly - unattended)
> >
> > This bug might get fixed in the latest version of mysql.  I see you
> > updated it last night.  I'll run a fresh compile tonight, and if the bug
> > is fixed, I'll change the script back.
> 
> It's broke for a very long time, I doubt it's fixed.

We can always hope!  :-)

 - BS

Quoting Bruce Smith <bw...@ar...>:

>> > --- mysql	27 Mar 2008 14:27:03 -0000	1.23
>> > +++ mysql	10 Apr 2008 14:00:51 -0000	1.24
>> > @@ -56,7 +56,7 @@
>> >  		rm $TMPDIR/usr/lib/*.la || exit 1
>> >  		copy_docs $TMPDIR
>> >  		rm -rf $TMPDIR/usr/mysql-test || exit 1
>> > -		cp $TMPDIR/usr/share/mysql/my-small.cnf $ETCDIR/etc/my.cnf || exit 1
>> > +		sed 's/^\[mysqld\] *$/&\nuser\t\t= mysql/'
>> > $TMPDIR/usr/share/mysql/my-small.cnf > $ETCDIR/etc/my.cnf || exit 1
>> >  		mkdir -p $CDDIR
>> >  		copy_files $TMPDIR/usr $CDDIR || exit 1
>> >  		rm -rf $TMPDIR || exit 1
>> >
>>
>> Should we add this statement to the init script for mysql?
>
> You mean add the user line to my.cnf in the init.d script, instead of
> giving them the default my.cnf with the user line already in there?

I was thinking about a check, if it's not in there then add it,  
otherwise ignore.

>> This would help us with custom my.cnf files, but would prevent users
>> from changing the username for mysql
>
> I hate to go mucking with someone's customized config files without
> telling them.  (and we can't ask for confirmation, because we're trying
> to make it boot correctly - unattended)
>
> This bug might get fixed in the latest version of mysql.  I see you
> updated it last night.  I'll run a fresh compile tonight, and if the bug
> is fixed, I'll change the script back.

It's broke for a very long time, I doubt it's fixed.

>> (is anybody really doing that?).
>
> I seriously doubt it.  :-)

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

> > --- mysql	27 Mar 2008 14:27:03 -0000	1.23
> > +++ mysql	10 Apr 2008 14:00:51 -0000	1.24
> > @@ -56,7 +56,7 @@
> >  		rm $TMPDIR/usr/lib/*.la || exit 1
> >  		copy_docs $TMPDIR
> >  		rm -rf $TMPDIR/usr/mysql-test || exit 1
> > -		cp $TMPDIR/usr/share/mysql/my-small.cnf $ETCDIR/etc/my.cnf || exit 1
> > +		sed 's/^\[mysqld\] *$/&\nuser\t\t= mysql/'  
> > $TMPDIR/usr/share/mysql/my-small.cnf > $ETCDIR/etc/my.cnf || exit 1
> >  		mkdir -p $CDDIR
> >  		copy_files $TMPDIR/usr $CDDIR || exit 1
> >  		rm -rf $TMPDIR || exit 1
> >
> 
> Should we add this statement to the init script for mysql?

You mean add the user line to my.cnf in the init.d script, instead of
giving them the default my.cnf with the user line already in there?

> This would help us with custom my.cnf files, but would prevent users  
> from changing the username for mysql 

I hate to go mucking with someone's customized config files without
telling them.  (and we can't ask for confirmation, because we're trying
to make it boot correctly - unattended)

This bug might get fixed in the latest version of mysql.  I see you
updated it last night.  I'll run a fresh compile tonight, and if the bug
is fixed, I'll change the script back.

> (is anybody really doing that?).

I seriously doubt it.  :-)

 - BS

Quoting Bruce Smith <bl...@us...>:

> Update of /cvsroot/devil-linux/build/scripts
> In directory sc8-pr-cvs12.sourceforge.net:/tmp/cvs-serv5853/scripts
>
> Modified Files:
> 	mysql
> Log Message:
> Add user to my.cnf
>
>
> Index: mysql
> ===================================================================
> RCS file: /cvsroot/devil-linux/build/scripts/mysql,v
> retrieving revision 1.23
> retrieving revision 1.24
> diff -u -d -r1.23 -r1.24
> --- mysql	27 Mar 2008 14:27:03 -0000	1.23
> +++ mysql	10 Apr 2008 14:00:51 -0000	1.24
> @@ -56,7 +56,7 @@
>  		rm $TMPDIR/usr/lib/*.la || exit 1
>  		copy_docs $TMPDIR
>  		rm -rf $TMPDIR/usr/mysql-test || exit 1
> -		cp $TMPDIR/usr/share/mysql/my-small.cnf $ETCDIR/etc/my.cnf || exit 1
> +		sed 's/^\[mysqld\] *$/&\nuser\t\t= mysql/'  
> $TMPDIR/usr/share/mysql/my-small.cnf > $ETCDIR/etc/my.cnf || exit 1
>  		mkdir -p $CDDIR
>  		copy_files $TMPDIR/usr $CDDIR || exit 1
>  		rm -rf $TMPDIR || exit 1
>

Should we add this statement to the init script for mysql?
This would help us with custom my.cnf files, but would prevent users  
from changing the username for mysql (is anybody really doing that?).

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hello,

Fred Frigerio wrote:
> How would one setup a gre tunnel in devil-linux? Just to be clear, I was
> able to get it working by hand. I am not asking how to set up the tunnel
> itself, but whether there is a formal configuration file (network?)
> where I can set them up. I poked around and it seems it would be in the
> /etc/sysconfig/nic but I am not sure what to do there.
> 
> Any ideas? Has anyone done them?

Well, I have to admit that there is no an elegant solution or I don't know it.
Your request is moved me to review the network configuration in DL and I think
the time to discuss it has come. DL really has difficulties with ipv6, tunneling
(ip-ip. gre, static ipsec/psk etc), teql and other exotic interfaces
configuration we will probably wish to configure.
To be more constructive I'd like to suggests several possibilities:
- sync network initialization with the latest RH based systems
- change network initialization to Debian like style and sync it with the latest
Debian system
- add an alternative network initialization system and allow to switch between
them. I mean etcnet project http://etcnet.org/.
- other suggestions ?

Bruce, Heiko, may I ask you about your thoughts?
I'm sorry in advance, due to my current overloading I can't answer quickly :-(

--
Sincerely,
Serge Leschinsky

> It's fine with me if you want to scrap grsec.   :-)

Let me think about it....

NOPE !

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

It's fine with me if you want to scrap grsec.   :-)

 - BS


> This means more security without grsecurity installed.
> 
> Heiko
> 
> ---------------------------- Original Message ----------------------------
> Subject: PIE Randomizations 2.6.25 kernel
> From:    "Kevin Day" <the...@gm...>
> Date:    Thu, April 3, 2008 08:10
> To:      "Hardened LFS Development List" <hlf...@li...>
> --------------------------------------------------------------------------
> 
> For those who aren't already aware:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cc503c1b43e002e3f1fed70f46d947e2bf349bb6
> 
> This is just an FYI
> 
> -- 
> Kevin Day
> -- 
> http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/

This means more security without grsecurity installed.

Heiko

---------------------------- Original Message ----------------------------
Subject: PIE Randomizations 2.6.25 kernel
From:    "Kevin Day" <the...@gm...>
Date:    Thu, April 3, 2008 08:10
To:      "Hardened LFS Development List" <hlf...@li...>
--------------------------------------------------------------------------

For those who aren't already aware:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cc503c1b43e002e3f1fed70f46d947e2bf349bb6

This is just an FYI

-- 
Kevin Day
-- 
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> Coreutils passed all checks on my build station.
> 
> OK, I guess I won't worry about the message then.  :-)
> 
>  - BS

I had the same message, but everything works normal.

But nevertheless maybe someone smarter than me should look what causes the problem,
because as far as i know, this message has something to do with a format string error.
And as a "security product" we should care eventually :-/

That's what i found:
> No, that's not the point.  It doesn't matter whether the target of the
> %n is writable; if it's not, we'll just segfault.  The test is supposed
> to prevent a malicious attacker inserting %n into the application
> somewhere where it will be passed to printf, causing an unexpected
> store.

Here is the full message:
> http://sources.redhat.com/ml/libc-alpha/2006-02/msg00078.html

..but though - this has nothing to do with coreutils, but....

- ----

Olli

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org

iD8DBQFH80p5724ZL5LNhNcRAplkAJ9X1Ghyjqx0Rq6aiYoVJlBUdGIBuwCfauW4
gP8P54/dvN1piID+WYYSTH4=
=/yoq
-----END PGP SIGNATURE-----

> > OK, but I'm not sure if the message is something we need to worry about?
> > Are all the coreutil programs being compiled and do they run?
> 
> I added "make check" specially to make sure it's working. I disabled one test
> which may be passed only if the box is online (I added a comment about it)
> 
> Coreutils passed all checks on my build station.

OK, I guess I won't worry about the message then.  :-)

 - BS

Bruce,

Bruce Smith wrote:

> OK, but I'm not sure if the message is something we need to worry about?
> 
> Are all the coreutil programs being compiled and do they run?

I added "make check" specially to make sure it's working. I disabled one test
which may be passed only if the box is online (I added a comment about it)

Coreutils passed all checks on my build station.

--
Sincerely,
Serge Leschinsky

> > executing coreutils with option build (in /data/build/tmp/coreutils-6.10)
> > *** %n in writable segment detected ***
> ...
> > It didn't abort, as my compile is still running.  Anyone have a clue?
> > 
> Yes, I was also interested in it.
> Please read this thread to clear the question - I'm not sure I'm able to retell it.
> 
> http://www.nabble.com/vasnprintf's-%22-n-in-writable-segment%22-chokes-with-_FORTIFY_SOURCE-%3D%3D-2-td13270892.html

OK, but I'm not sure if the message is something we need to worry about?

Are all the coreutil programs being compiled and do they run?

 - BS

Hi Bruce,

Bruce Smith wrote:

> executing coreutils with option build (in /data/build/tmp/coreutils-6.10)
> *** %n in writable segment detected ***
...
> It didn't abort, as my compile is still running.  Anyone have a clue?
> 
Yes, I was also interested in it.
Please read this thread to clear the question - I'm not sure I'm able to retell it.

http://www.nabble.com/vasnprintf's-%22-n-in-writable-segment%22-chokes-with-_FORTIFY_SOURCE-%3D%3D-2-td13270892.html

--
Sincerely,
Serge Leschinsky