This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 252997 - open() aborts process when not used correctly.
open() aborts process when not used correctly.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
: Reopened
Depends On: 252440
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-16 11:03 EDT by Steve Dickson
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-16 11:59:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Steve Dickson 2007-08-16 11:03:39 EDT
Description of problem:
the open system call has be changed in the glibc so if
a mode is not passed in during an O_CREATE open, the
process is aborted.

Version-Release number of selected component (if applicable):


How reproducible:
main()
    int readonly = 0;
    char *fname = "/tmp/foo";

    open(fname, readonly? O_RDONLY : (O_RDWR|O_CREAT));
}
will cause the process to abort.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jakub Jelinek 2007-08-16 11:15:06 EDT
That's the same action as we use for -fstack-protector overflows, or for
-D_FORTIFY_SOURCE{,=2} check failures.  In all cases it is something that needs
immediate fix in the source, I'd add especially with open one that is very easy.
Comment 2 Peter Staubach 2007-08-16 11:25:11 EDT
Aren't those things that the application could not handle, at least easily?

A failing open system call is handleable.

A library should not be calling abort() or exit().
Comment 3 Jakub Jelinek 2007-08-16 11:28:58 EDT
Please don't reopen this, glibc won't change.
Comment 4 Peter Staubach 2007-08-16 11:40:20 EDT
THen who do we appeal to when incorrect decisions are made which can
affect _every_ application on the system?
Comment 5 Peter Staubach 2007-08-16 11:49:14 EDT
Were other, less drastic solutions considered?  Such as logging messages
with syslog()?
Comment 6 Jakub Jelinek 2007-08-16 11:59:16 EDT
Yes and they were dismissed.
This is a really serious bug, often with bad security consequences, exactly
the same as buffer overflows, app memory management errors on the heap, etc.
All cases are handled the same, by aborting with an error message and we were
doing that for years (some checks already in RHEL3, further ones added in RHEL4,
then new ones in RHEL5, then now in F8 again a new check).
With an abort you 1) stop the app from doing something that can have security
consequences immediately 2) very loudly tell the user the application is broken,
which allows immediate or almost immediate fixing of the problem.
You can look at history, all kinds of bugs reported this way are usually very
quickly fixed, whether it is memory management errors causing malloc to complain
and abort, or buffer overflow, etc.
Comment 7 Steve Dickson 2007-08-16 14:19:47 EDT
Here is the disscusion on the public Fedora Maintainers mailing list:

https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00265.html

Note You need to log in before you can comment on or make changes to this bug.