Re: supporting terminal ownership assignment (tcsetpgrp()) in posix_spawn

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 07/06/2021 18:23, Godmar Back wrote:
> On Mon, Jun 7, 2021 at 5:04 PM Adhemerval Zanella <
> adhemerval.zanella@linaro.org> wrote:
> 
>>
>>
>> On 03/06/2021 10:58, Godmar Back via Libc-help wrote:
>>> I've recently been playing with posix_spawn() and noticed that it lacks
>>> support for assigning terminal ownership (as would be done via
>>> tcsetpgrp()). As a consequence, it cannot be used for job control shells
>>> when starting jobs in the foreground [1].
>>>
>>> IBM's implementation of spawn [2] for zOS supports SPAWN_SETTCPGRP for
>> this
>>> reason.
>>>
>>> Even though the POSIX spec states "Future Directions: None" I came across
>>> this Austin group issue [3] which proposes to add a way to set the child
>>> process's session id, and which appears to have been accepted in 2016.
>> This
>>> is an example of evolution of posix_spawn.
>>>
>>> Is anyone aware of efforts to add something similar to POSIX, and more
>>> specifically, to Linux?
>>>
>>> If the current implementation of posix_spawn is library based (I'm
>> guessing
>>> it is) then there would be nothing to prevent Linux from adding
>> additional
>>> flags, just like QNX or Blackberry have already done ([3]).
>>
>> Other OS might provide a syscall for posix_spawn (I know MacOSX does and
>> I think maybe Solaris as well), but for Linux is done on top of clone
>> syscall.
>>
>> And glibc alread supports POSIX_SPAWN_SETSID since 2.26, so why can't you
>> use it along with with tcsetpgrp() called from the parent?
> 
> 
> SETSID sets a new session, which is a different concept than the foreground
> process group of a
> controlling terminal.
> 
> tcsetpgrp() informs the OS which process group shall be the foreground
> process group of the
> terminal to which it is applied.  However, this can't be called by the
> parent since the parent
> doesn't know the process group id of the process that will be spawned by
> the call to posix_spawn().
> 
> This process id (and the corresponding process group id) is known to the
> parent only after the
> call to posix_spawn() was made (and has returned). By that point, it's too
> late to set the controlling
> terminal's foreground process group. Specifically, by the time posix_spawn
> returns, the child process
> may have already acted under the assumption that it has ownership of the
> terminal. Since the
> child process is in a separate process group (because POSIX_SPAWN_SETPGROUP
> was given to
> posix_spawn()), this may lead to the suspension of the child process via
> SIGTTIN/SIGTTOU.
> 
> Thus, calling tcsetpgrp() from the parent after the fact cannot be done in
> a race-free fashion, one
> needs to ensure that it's done after placing the child in a new process
> group but before exec'ing the
> child's executable.

Yeah I forgot the inherent race condition on this scheme.  I think it
should be possible to add such interface as a posix_spawn file action:

  int posix_spawn_file_actions_tcsetpgrp_np (int fd)

Not sure if it make sense to support a pid different than the created
helper process (which will eventually call execve) since it is something
the parent can do it itself.

> 
> In Linux's library-based implementation of posix_spawn(), support
> for POSIX_SPAWN_TCSETPGROUP
> could be easily added - my question is why hasn't it?

I would say because POSIX does not define it in the standard and no one
has asked it before.