From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-044.btinternet.com (mailomta4-sa.btinternet.com [213.120.69.10]) by sourceware.org (Postfix) with ESMTPS id C049238582AF for ; Sat, 8 Oct 2022 15:18:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C049238582AF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.38.4]) by sa-prd-fep-044.btinternet.com with ESMTP id <20221008151824.KUJD711.sa-prd-fep-044.btinternet.com@sa-prd-rgout-001.btmx-prd.synchronoss.net>; Sat, 8 Oct 2022 16:18:24 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 62E573CC0B3D99F0 X-Originating-IP: [81.129.146.212] X-OWM-Source-IP: 81.129.146.212 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeiledgkeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfhffufhfvjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepleetudfhgfffgfevkedvudejkeevteelveffleduvdekueekudehffffjeehvdegnecukfhppeekuddruddvledrudegiedrvdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduvdelrddugeeirddvuddvpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopefuthhrohhmvghkohesnhgvgihgohdruggvpdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.129.146.212) by sa-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 62E573CC0B3D99F0; Sat, 8 Oct 2022 16:18:24 +0100 Message-ID: <3f6098ed-0b64-33f2-c8ca-36a92500adbb@dronecode.org.uk> Date: Sat, 8 Oct 2022 16:18:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 From: Jon Turney Subject: Re: [Bug] setup regression #2 References: <87pmfn5o2j.fsf@Rainer.invalid> <0c8c757c-4f6b-3b49-5404-99353de48b1b@dronecode.org.uk> <877d1gd83r.fsf@Rainer.invalid> Content-Language: en-GB To: "cygwin-apps@cygwin.com" , Achim Gratz In-Reply-To: <877d1gd83r.fsf@Rainer.invalid> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1193.3 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 03/10/2022 20:23, Achim Gratz wrote: > Jon Turney writes: >> This problem is with files created by setup, or by post-install scripts? > > I think both, although the problematic symlinks were created through > alternatives. That's pretty baffling. I don't see how any of those commits would change the ownership of files created by setup itself. The only relevant change seems to be in "Defer setting group until after All Users/Just For Me is chosen", I've made nt_sec.resetPrimaryGroup() explicit, but that only happens for non-admin installs... >> (I'm not sure how these commits could have caused the former, if the >> latter then reverting 45d8e84e "Drop group change while running >> postinstall scripts" would be the thing to try...) > > As I said, I don't understand it either. It seems my installations were > all using the primary group for the account that does the install (which > does have administrative rights and is separate from my normal user > account on most machines). The primary group is either "None" for the > build machine that only uses local accounts and is not a member of any > domain or "Domain Users" otherwise. > > The new code uses "Administrators", but that seems to have the side > effect of denying "normal" users access to the installation and instead > weaves in extra DACL for SYSTEM. > > As long as there's an option to force it to keep the former behaviour > things should be OK, but I haven't really checked if and how this is > possible. Unfortunately, there is no such option.