This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dup3/O_CLOEXEC/F_DUPFD_CLOEXEC


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

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]