FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 01-10-2012, 12:41 AM
Tom Lane
 
Default Override with -D_FORTIFY_SOURCE=0 as workaround allowed?

Robert Scheck <robert@fedoraproject.org> writes:
> [ _FORTIFY_SOURCE=2 breaks non-default FD_SETSIZE settings ]

So far as I can see from the sys/select.h header file, there is no
intention for glibc to support overriding the value of FD_SETSIZE;
certainly, doing so doesn't affect sizeof(struct fd_set). It's possible
that it'd work if you don't use that struct declaration, but then you're
definitely outside the boundaries of what can be called portable code.
So while you'll probably want an authoritative opinion from a glibc
maintainer, I'd venture that overriding FD_SETSIZE is a nonportable
BSD-ism.

I think the reason this hasn't been complained of too much is that
it's generally better to use poll(2) instead of select(2) if your
program can have a lot of file descriptors open. Have the Zarafa
developers considered offering a poll()-based option?

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 01-10-2012, 09:31 AM
Kamil Dudka
 
Default Override with -D_FORTIFY_SOURCE=0 as workaround allowed?

On Tuesday 10 January 2012 11:25:39 Robert Scheck wrote:
> Hello Tom,
>
> On Mon, 09 Jan 2012, Tom Lane wrote:
> > I think the reason this hasn't been complained of too much is that
> > it's generally better to use poll(2) instead of select(2) if your
> > program can have a lot of file descriptors open. Have the Zarafa
> > developers considered offering a poll()-based option?
>
> I have taken that topic already to Zarafa, more than void was not yet
> returned, however there is an internal developer meeting this week, I
> think.
>
> Even if they decide to rewrite the code, it's not done immediately and
> non-paid code rewrites maybe also take some time, it's similar like at
> RHEL vs. subscription, if I'm allowed to compare.
>
> Would -D_FORTIFY_SOURCE=0 be acceptable until the code is rewritten?

If you prefer undefined behavior over valid assertion failure, then yes.

Kamil
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 01-10-2012, 02:16 PM
Tom Lane
 
Default Override with -D_FORTIFY_SOURCE=0 as workaround allowed?

"Daniel P. Berrange" <berrange@redhat.com> writes:
> On Tue, Jan 10, 2012 at 11:25:39AM +0100, Robert Scheck wrote:
>> Would -D_FORTIFY_SOURCE=0 be acceptable until the code is rewritten?

> As Tom pointed out, if you override FD_SETSIZE with glibc, this has
> no effect on the size of the 'fd_set' struct. So any attempt to
> actually store a larger number of FDs will be writing outside
> the bounds of the struct. ie it will be corrupting heap/stack
> memory. This is the kind of flaw that leads to crashes at best,
> or security exploits at worst.

Perhaps a more reliable workaround would be to patch in some code at
program start that reduces the soft limit on number of open files to
1K or less (see setrlimit(RLIMIT_NOFILE)). This would presumably
reduce performance by some fractional amount, but that seems better
than the unsafe behavior you're looking at now.

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 04:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org