On 04/11/2012 01:23 PM, KOSAKI Motohiro wrote:
Hmmm.... I'm sorry I don't find "considered undesirable". Maybe because
my English is not very good. can you please help me clarify?
I also went and read the mailing list discussion on the topic.
Ulrich, for example (in his usual mild-mannered style), commented:
And all these programs and systems are wrong.
There is no guarantee that one of the fds isn't used behind the
scenes for something important which is still running as part of the
fork/exec code. It's completely unacceptable to build into the
interfaces the assumption that the programmer knows all the file
descriptors.
This is why using CLOEXEC is the only correct way to deal with this
and now there is no exceuse anymore whatsoever. Every fd-creating
interface can use CLOEXEC.
This text says,
so a future revision of the standard may indeed add fdwalk( ), although no
one in the meeting was willing to draft a proposal for fdwalk( ) at this time
and, later says after noting F_NEXT and O_CLOEXEC,
Therefore, the rest of this proposal seeks to document the problem
with closing arbitrary file descriptors, and a new bugid will be
opened to propose standardizing some recent interfaces and interface
extensions first appearing in Linux
Do you think latter override former?
Yes.
b) unsafe because there might be file descriptors used by libc itself.
I agree this. Even though almost developer don't use libc message catalogue and
we can avoid such issue by using nextfd() + fcntl(O_CLOEXEC).
No, that's exactly the point that we cannot.
I thknk we are talking different aspect. I'm talking practical issue.
say, ruby hit the exact same issue
because valgrind uses internal fds and they don't think their exec()
case don't need fd
inheritance. Even though it close libc internal fds, invoked new
executable may open them
again at process strtup code. Therefore, they are using O_CLOEXEC. In
the other hands,
you seems talking about it is corner case. If so, I agree. I was not
argue it. I only say, I
haven't seen real world application require it.
Personally, I'm only interesting real world issue.
These are real-world issues.
The problem -- as was brought up in the POSIX discussion -- is that you
actually end up breaking *properly functioning programs*.
But the url only talk about a possibility of misuse.
There are concrete examples on the mailing list.
Anyway, fdwalk() at least exists as an interface. There is absolutely
no momentum for FD_NEXT that I can see.