apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46425] Apr should set FD_CLOEXEC if APR_FOPEN_NOCLEANUP is not set
Date Sun, 22 Feb 2009 12:41:20 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46425





--- Comment #8 from Stefan Fritsch <sf@sfritsch.de>  2009-02-22 04:41:19 PST ---
(In reply to comment #4)
> > I haven't checked what happens if apr is compiled on a system with O_CLOEXEC and
then is used on a system without O_CLOEXEC.
> 
> Do we allow this kind of thing to be done at all? After all, we try to detect
> what is available during configure time, so that we can reliably use that
> later. All kinds of things will break if APR compiled on one system is used on
> another that doesn't have those features available.
> 
> Take gethostbyname/getservbyname() stuff - we detect that during compile. If we
> move such APR to another machine that is lacking what we detected, it won't
> work. Same with O_CLOEXEC, dup3 etc.

At least apr should break in an obvious way if one does this. If new syscalls
are used, this is ok because the error will be noticed.

But if the flag is silently ignored on older systems as is the case with
O_CLOEXEC on linux, this may cause subtle breackage or even create security
issues. In this case we should either verify that O_CLOEXEC works during run
time (a PITA), or just use fcntl in addition to be on the save side.

If we can be sure that O_CLOEXEC is supported, the additional fcntl call could
be ommited. For example, any linux system that supports dup3 also supports
O_CLOEXEC.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message