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

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

On 08/06/2021 11:37, Godmar Back wrote:
> On Tue, Jun 8, 2021 at 9:50 AM Adhemerval Zanella <
> adhemerval.zanella@linaro.org> wrote:
> 
>>
>> So one options might be to add something as the one I suggested before,
>> but as generic extension instead of a file extension (which does not make
>> sense in fact):
>>
>>   int posix_spawnattr_tcsetpgrp_np (posix_spawnattr_t *__attr, int fd,
>> pid_t pgrp);
>>
>>   Similar to tcgetpgrp, it make the created process group with process
>> group
>>   instructed by the PGRP argument the foreground process group on the
>> terminal
>>   associated to FD.  If PGRP is 0, the current group obtained with
>> getpgrp()
>>   will be used, otherwise PGRP will be used.
>>
>>   This is done after just after setting the process group ID
>>   (POSIX_SPAWN_SETPGROUP) and right before setting the effective user and
>>   group id (POSIX_SPAWN_RESETIDS).
>>
>> So if the called want to create a new session id, it can issue:
>>
>>   posix_spawnattr_t attr;
>>   posix_spawnattr_setflags (&attr, POSIX_SPAWN_SETSID);
>>   posix_spawnattr_tcsetpgrp_np (&attr, fd, 0);
>>
>> And the created process will issue the following in the order:
>>
>>   setsid ();
>>   tcsetpgrp (fd, getpgid (0));
>>
>>
> After setsid(), the caller is a new session leader and a new process group
> leader, but it doesn't have a controlling terminal.
> (setsid(2) says: "The calling process will be the only process in the new
> process group and in the new session. Initially, the new session has no
> controlling terminal.")
> 
> The man page of tcsetpgrp however states that the fd passed: "must be the
> controlling terminal of the calling process."
> So if you implemented it like that in a library, it should fail based on
> the description in the man pages.
> 
> I'm not sure if POSIX_SPAWN_SETSID needs to be able to be combined with
> setting the terminal's foreground process group. Those are different use
> cases. In the case of setsid, the spawned process must be prepared to
> become a new session leader (open a new controlling terminal, etc.) so it
> would not generally assume to already be a member of the terminal's fg
> process group (since it doesn't have a controlling terminal yet).

Indeed this won't accomplish anything in fact, one will need to issue
a ioctl with TIOCSCTTY to recover the terminal (as login_tty does). I
agree with you that the usual usercase for POSIX_SPAWN_SETSID is to 
have the created process to setup itself the required terminal.

There is hacks to reparent a running program to a new terminal by using
ptrace to inject syscalls on the target process, but I think it is
really out of scope from the libc.

> 
> 
>>
>> If the caller already has group it want to use, it can issue instead:
>>
>>   posix_spawnattr_t attr;
>>   posix_spawnattr_setpgroup (&attr, groupid);
>>   posix_spawnattr_tcsetpgrp_np (&attr, fd, groupid);
>>
>> Which in turn will make the created process to issue:
>>
>>   setpgid (0, groupid);
>>   tcsetpgrp (fd, groupid);
>>
> 
> For this use case, as long as it supports groupid == 0, this should work as
> it is what shells currently do.

So the my question is whether providing the groupid as an argument is
really required (I would say yes so it can be combined with
posix_spawnattr_setpgroup).

Another question is when to issue the tcsetpgrp related to
POSIX_SPAWN_SETSID. I would say tcsetpgrp should be issued *before*
setsid, so tcsetpgrp can return early if it fails. Otherwise tcsetpgrp
will always fail if POSIX_SPAWN_SETSID is set (it would be a caller
error, but I think from API viewpoint it should be better if we could 
minimize the possible error scenarios).