From owner-freebsd-stable@freebsd.org Mon Jan 6 18:13:36 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D4DB31DBCCB for ; Mon, 6 Jan 2020 18:13:36 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47s3Xt6Q1Cz42Wb for ; Mon, 6 Jan 2020 18:13:34 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.16.0.41/8.16.0.41) with ESMTPS id 006ID4HQ016154 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 6 Jan 2020 19:13:05 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.16.0.41/8.16.0.41/Submit) with UUCP id 006ID4Cj016153 for freebsd-stable@FreeBSD.ORG; Mon, 6 Jan 2020 19:13:04 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id 006HQNTe053115 for ; Mon, 6 Jan 2020 18:26:23 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id 006HO0vF052937 for ; Mon, 6 Jan 2020 18:24:01 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id 006HO0O3052936 for freebsd-stable@FreeBSD.ORG; Mon, 6 Jan 2020 18:24:00 +0100 (CET) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: Re: session mgmt: does POSIX indeed prohibit NOOP execution? Date: Mon, 06 Jan 2020 18:18:21 +0100 Organization: n/a Message-ID: References: <20200106001057.GA64665@elch.exwg.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Injection-Info: oper.dinoex.de; logging-data="52172"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Opera Mail/12.16 (FreeBSD) Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.org [185.220.148.12]); Mon, 06 Jan 2020 19:13:08 +0100 (CET) X-Rspamd-Queue-Id: 47s3Xt6Q1Cz42Wb X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of li-fbsd@citylink.dinoex.sub.org has no SPF policy when checking 2001:1440:5001:1::2) smtp.mailfrom=li-fbsd@citylink.dinoex.sub.org X-Spamd-Result: default: False [5.47 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999,0]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; TO_DN_NONE(0.00)[]; IP_SCORE(0.27)[ip: (0.71), ipnet: 2001:1440::/32(0.36), asn: 8469(0.29), country: DE(-0.02)]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[peter@citylink.dinoex.sub.org,li-fbsd@citylink.dinoex.sub.org]; DMARC_NA(0.00)[sub.org]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8469, ipnet:2001:1440::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[peter@citylink.dinoex.sub.org, li-fbsd@citylink.dinoex.sub.org] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:13:36 -0000 On Mon, 06 Jan 2020 01:10:57 +0100, Christoph Moench-Tegeder wrote: >> When a program is invoked via /usr/sbin/daemon, it should already be >> session leader AND group leader, and then the above code WOULD be a >> NOOP, unless POSIX would require the setpgid() to fail and thereby the >> program to abort - which, btw, is NOT a NOOP :( > > https://pubs.opengroup.org/onlinepubs/9699919799/ > "The setpgid() function shall fail if: [...] The process indicated by > the > pid argument is a session leader." Okay, so, what You are saying is that I got correct information insofar that POSIX indeed demands the perceived behaviour. Thanks for that confirmation. > Not much room to argue? Why that? This is not about laws you have to follow blindly whether you understand them or not, this is all about an Outcome - a working machine that should properly function. So either there are other positive aspects in this behaviour that weight against the perceived malfunction, or the requirement is simply wrong. And the latter case should be all the argument that is needed. I do not say disobey Posix. I only say that one of the involved parts must certainly be wrong, and that should be fixed. So if You are saying, the problem is in Posix, but we are in the role of blind monkeys who have to follow that alien commandment by all means no matter the outcome, then this does not seem acceptable to me. Actually, as it seems to me, this whole session thing came originally out of Kirk McKusick's kitchen and made its way from there into Posix, so if there is indeed a flaw in it, it should well be possible to fix it going the same way. In any case, this here (to be found in /etc/rc,d/kadmind) is a crappy workaround and not acceptable style: > command_args="$command_args &" We aren't slaves, or, are we? I for my part came just accidentially across this matter, and as my stance is, 1. the code has to be solid enough to stand the Jupiter mission, and therefore 2. do a rootcause Always, on Every misbehaviour (and then fix it once and for all), so I figured that thing out. rgds, PMc