From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2663 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: chpst -u and supplementary groups Date: Tue, 20 Aug 2019 18:21:09 +0000 Message-ID: References: <20190819120807.v4f2xe2mwjky3p2p@klumpi.ignorelist.com> <1222e286-60ed-4790-7aa9-6c4f78c52cd0@ntlworld.com> <20190820100433.rlioufyvxodvwkpc@klumpi.ignorelist.com> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="40320"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.34711.0 To: "supervision@list.skarnet.org" Original-X-From: supervision-return-2253-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Aug 20 20:21:22 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i08l0-000AOW-7V for gcsg-supervision@m.gmane.org; Tue, 20 Aug 2019 20:21:22 +0200 Original-Received: (qmail 21754 invoked by uid 89); 20 Aug 2019 18:21:46 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 21747 invoked from network); 20 Aug 2019 18:21:46 -0000 In-Reply-To: <20190820100433.rlioufyvxodvwkpc@klumpi.ignorelist.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2663 Archived-At: >Yes. Apparently everyone re-implementing daemontools does something like >this. So that brings me back to my original question: is there consensus >that the historical behaviour is a bug? Or are there valid use cases=C2=B9= ? I don't think the historical behaviour is a *bug*, because the historical behaviour is documented and conforms to its documentation. It also comes from a time when supplementary groups weren't used as much as they are today. It's just that not having supplementary groups can defeat intuitive expectations when performing a group permissions check. That does not happen every day, but it does happen sometimes. s6-setuidgid had the same behaviour as setuidgid until I got bitten by that very problem, at which point I realized that "user identity" is not only uid and gid as it is for files, but also supplementary groups, and so I added supplementary groups support to s6-*uidgid. But it had been years until I found it necessary. So, YMMV. I'd say supplementary groups support is useful and allows the tool to better match user intuition, so it has value. But is it *mandatory* for correctness? You decide. -- Laurent