From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by sourceware.org (Postfix) with ESMTPS id 7A8D2382E832 for ; Mon, 7 Jun 2021 21:36:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A8D2382E832 Received: by mail-qk1-x72b.google.com with SMTP id j184so18236554qkd.6 for ; Mon, 07 Jun 2021 14:36:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h29XTlbMrT2KioafsdNCTs85HH5vKpmlYTniCjtsO9E=; b=SGyx2+CERVqusOvuC/2/VENEqLgsx8l7IN1h/3uVacEwtoVpugr0veZRpMcfsTdFDB W/Y3euYtJgQ/atlPE7pMagEG+nJ1IAAGobQltUy3Z7rKr3J920qLLa+pm1Hk+8c6XoaZ tV4E+09CBKXcd08pADA0+hjKBIS+O6y+k/XrlURxLj2JTpgUmYTMwxXe3VRfyex3EfTQ lNDJlXxla7JMGWLGtRhsDMxEOHWEXIW5L1HdQUiuiHKexrsUymb4IRbrIF0EWqF4UABx /7oMwrZMQTxI8c/aFH3rY1y+zO3gSKu2YsOnb5NNtyib5oe1wzaOpuPbV1sQkV04OdpA ygFg== X-Gm-Message-State: AOAM530QpJ3kyLKh+WqBpEDtfL3I7EdahVHltp1kfc3boBbGhvf71Xka DkUXYW5jAXxaNIv+zJ4/hv31B+uUqO6VRQ== X-Google-Smtp-Source: ABdhPJwTkd6P0hbAI4xpqk0ZZuUwGLKBAANSmpB6Q864ayZxHc5iy2RBB52o3QCmYR1LyfNnbKBFyA== X-Received: by 2002:a37:b445:: with SMTP id d66mr18655501qkf.403.1623101802901; Mon, 07 Jun 2021 14:36:42 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id f9sm1835858qkl.46.2021.06.07.14.36.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 14:36:42 -0700 (PDT) Subject: Re: supporting terminal ownership assignment (tcsetpgrp()) in posix_spawn To: Godmar Back Cc: Libc-help References: <7298cb72-becb-80bb-b2df-d97bdb201e95@linaro.org> From: Adhemerval Zanella Message-ID: Date: Mon, 7 Jun 2021 18:36:40 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 21:36:53 -0000 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.