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

[Steve Dickson]

Eric Sandeen wrote:
> It also says:
> 
>        mode must be specified when O_CREAT is in the flags, and is
> ignored otherwise.
> 
> Hard to argue with the "must"
point... I did miss this in the man page. Thank you for pointing
this out...

>>> And yes, its conceivable the stack contents could create 
>>> a world writable setuid file which cannot ever be the intended operation.
>> The key word being "conceivable"... a hole that size would have been
>> found a long time ago... and because of these new constraints a
>> hole of this type not happen, which is a good thing... but just because
>> some this is conceivable does not justify killing processes...
>>
>> exportfs does not write setuid files, but it can cause a lost
>> of thousand of dollars when a entire development department
>> is idle because they can't log in because we decided to change
>> the meaning of open()... it just does not make sense to me...
>>
>> Again, creating good program habits is a good thing, but at
>> what cost?
> 
> Is there an explicit security risk to exposing the stack via the
> uninitialized mode, in this way?
Yes.. I totally agree with (and understand) the security risk
of using uninitialized stack data... its wrong! But the question
is how we deal with it and how we give our development community
a chance to deal with it.

Coming out with an OS that blindly kills processes is just not
the way to handle it... imho... Make it a warning so developers
have a chance to fix it and then take stronger measures in
a later release would be a better way to handle this... again imho...

steved.