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

[adhemerval.zanella at linaro dot org]

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

--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Eric Blake from comment #3)
> (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).

I agree addfcntl would add a lot of complexity and we would need to add
extensive documentation it is only intended to provide a subset of default
fcntl operations (which I also think it is not a good idea).

> 
> 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).

Agreed.

> 
> 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().

It looks like some libcs (musl for instance) are already pushing this proposal
as expected behavior and I would like to avoid either adding a non-portable
extension or deviating from POSIX.

I will work on adding this support on GLIBC, thanks to bring this up.

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