This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

[Bug libc/23640] no way to easily clear FD_CLOEXEC in posix_spawn_file_actions_adddup2()


https://sourceware.org/bugzilla/show_bug.cgi?id=23640

--- Comment #3 from Eric Blake <eblake at redhat dot com> ---
(In reply to Adhemerval Zanella from comment #2)
> I think the rationale to have a posix_spawn operation to reset O_CLOEXEC is
> reasonable, but I am not very found of having dup2 and
> posix_spawn_file_actions_adddup2 with subtle different semantics: this
> usually lead to wrong assumptions, since posix_spawn file actions are in
> fact modeled based on POSIX counterparts.
> 
> I am not sure which would be the best extension to add though (maybe
> posix_spawn_file_actions_fcntl?).

Adding posix_spawn_file_actions_addfcntl seems like a lot of complexity. In
particular, the fact that you have to read-modify-write in order to properly
use fcntl() makes it rather verbose to have to add multiple fcntl actions to
file_actions, compared to having a single call just give the semantics you
want.  Another drawback of adding an _addfcntl is deciding what things it
supports, as well as documenting the vast majority of things it specifically
does not support (updating file locking, for example, seems like a huge growth
in scope and unlikely to ever be natively part of a spawn() syscall, but having
a spawn syscall that can clear FD_CLOEXEC on fds specifically requested for use
in the child does not seem difficult).

A posix_spawn_file_actions_adddup3() doesn't make much sense either - the
normal dup3() is specifically documented to require failure on dup3(fd, fd,
flags) (unlike dup2(fd, fd) which must be a no-op).

You could go with an even more simplistic approach, and add
posix_spawn_file_actions_addnocloexec(&act, fd) (instead of _adddup2(&act, fd,
fd)), where the different function name has no direct bare counterpart, but
makes it immediately obvious that its goal is to remove FD_CLOEXEC flags on fds
that must remain cloexec in the parent, but must be inherited by the child.

Of course, if glibc actually implements something different than the current
POSIX proposal, it's not too late to use that as feedback to update the POSIX
proposal to match existing practice (after all, the proposal is still just
that, and hasn't actually been incorporated into a released version of POSIX
yet).  I'm just pointing out that when this proposal was first vetted by the
Austin Group (several years ago now), no one had any better ideas for an easy
way to clear FD_CLOEXEC, besides making _adddup2() have a documented slightly
different behavior from normal dup2().

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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