[Nmh-workers] O_CLOEXEC
Ken wrote: ... yeah, I have to agree with you there. I think by now all library calls that create file descriptors should be setting the close-on-exec flag, right? That's been around forever. Although I'm not sure O_CLOEXEC has been around forever, has it? I know the fcntl() equivalent has. We should go through and audit all open() calls and set the FD_CLOEXEC flag where appropriate. O_CLOEXEC has been in Linux since 2.6.23. I'm stuck on at least one system (CentOS 5.9) that's older. As part of the audit, it would be really nice to wrap all open() calls so we can take care of this in one place. We could then easily autoconf check for O_CLOEXEC if desired. We wrap the alloc family and that's been very helpful. (Is 255 fixed? File descriptors can run far higher on some systems, and closing them all can take time, e.g. Apache used to suffer from this. The BSDs added http://manned.org/closefrom.2 to lessen the calls, but it still tramples willy-nilly.) It looks like it's based on OPEN_MAX ... which is kind of bogus. All of that is funneled through one function, closefds(), so easy to fix (remove in this case). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] O_CLOEXEC
As part of the audit, it would be really nice to wrap all open() calls so we can take care of this in one place. We could then easily autoconf check for O_CLOEXEC if desired. We wrap the alloc family and that's been very helpful. You know, if I had my druthers I'd rather just write the code to use the older but more widely supported fcntl() call to set FD_CLOEXEC; that would avoid an autoconf test and make Lyndon happier :-) Also, it looks like O_CLOEXEC is not actually part of POSIX? There are also a bunch of calls to fopen() and for that we'd need to use fcntl() there. (Is 255 fixed? File descriptors can run far higher on some systems, and closing them all can take time, e.g. Apache used to suffer from this. The BSDs added http://manned.org/closefrom.2 to lessen the calls, but it still tramples willy-nilly.) It looks like it's based on OPEN_MAX ... which is kind of bogus. All of that is funneled through one function, closefds(), so easy to fix (remove in this case). Hopefully closefds() can just go away? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] O_CLOEXEC
Ken wrote: You know, if I had my druthers I'd rather just write the code to use the older but more widely supported fcntl() call to set FD_CLOEXEC; that would avoid an autoconf test and make Lyndon happier :-) Also, it looks like O_CLOEXEC is not actually part of POSIX? There are also a bunch of calls to fopen() and for that we'd need to use fcntl() there. Good points. All the more reason to wrap the opens + fcntl(). David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] O_CLOEXEC
On Wed, Nov 12, 2014 at 11:49 AM, David Levine wrote: Good points. All the more reason to wrap the opens + fcntl(). Popping in real quick here, but if we are voting on this, I prefer the fcntl() route. I have a fairly old linux box that I still use nmh on. It is running a v2.4.20 linux kernel. Thanks, --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] O_CLOEXEC
On Nov 12, 2014, at 6:29 AM, David Levine levin...@acm.org wrote: As part of the audit, it would be really nice to wrap all open() calls so we can take care of this in one place. We could then easily autoconf check for O_CLOEXEC if desired. We wrap the alloc family and that's been very helpful. POSIX only defines the fcntl() interface, so that's the one we should be using. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
