dup3/O_CLOEXEC/F_DUPFD_CLOEXEC

[Eric Blake]

According to Corinna Vinschen on 1/14/2010 4:57 AM:
>> time to do that via the O_CLOEXEC flag.
> 
> Hang on, the file is closed anyway after the mmap call succeeded.
> That's not true for sem_open and shm_open, though.

Well, on Linux, it looks like sem_open does not need to keep the fd open.
 It all boils down to the question of any API that can hand a new fd back
to the user should have the ability to protect said fd with O_CLOEXEC at
creation time.

> 
> However, what kind of cleanup did you mean?  There's no EINVAL specified
> in POSIX for invalid open flags and invalid flags are already filtered
> out before calling open.

In a multi-threaded app, any fd that is opened only temporarily, such as
the one in mq_open, should be opened with O_CLOEXEC, so that no other
thread can win a race and do a fork/exec inside the window when the
temporary fd was open.  So even though mq_open does not leak an fd to the
current process, it should pass O_CLOEXEC as part of its internal open()
call in order to avoid leaking the fd to unrelated child processes.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 320 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20100114/afe86f97/attachment.sig>