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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
