The open() system call in f8 really broken...

[Oliver Falk]

On 08/16/2007 04:55 PM, Steve Dickson wrote:
> Oliver Falk wrote:
>> On 08/16/2007 04:34 PM, Steve Dickson wrote:
>>> Jakub Jelinek wrote:
>>>> On Thu, Aug 16, 2007 at 10:12:24AM -0400, Steve Dickson wrote:
>>>>> Bring down servers, costing people time and money because apps
>>>>> that have run for years suddenly abort is just not the right
>>>>> way to handle this.. imho..
>>>> Only people that run their $$$$$$ servers on rawhide...
>>> No.. but they do on RHEL and today's rawhide is tomorrow's RHEL...
>>
>> But Steve, they will not simply do a yum upgrade on their EL5 boxes to
>> upgrade to EL6...
> Agreed... And I'll concede moving from one RHEL release to another
> RHEL release is a good time to make people recompile their code
> esp for security issues... and their code should not compile if
> there is a security issue... But thats not the case here!
> 
> My code compile and then aborted... and even worse I was able
> to avoid the abort without fixing the security hole.. so the
> abort was basically meaningless...  imo...
> 
> So I guess what I'm saying, if you can't catch the security issue
> and fail the compilation, don't abort the process at run time.
> Issue a warning instead... Let the developers decide how
> grievous the problem, not glibc...

Most developers I know, don't worry about >warnings<, but do if their
code aborts. If a developer then doesn't worry about the real (security)
problem, but only about the abort itself and just workaround that - it's
simply a fault... The other option? stderr "FIX YOUR OPEN :-P"; sleep
600. :-)

If you compile the whole Fedora tree, how many warnings will you see?
How many warnings are about 'better use mkstemp' - for security
reasons... If you don't abort you'll not catch the developers
attention... It's too bad, but true... Don't want to step on dev's toes
of course - it's for sure not true for *all* developers!

-of