From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mr3.vodafonemail.de (mr3.vodafonemail.de [145.253.228.163]) by sourceware.org (Postfix) with ESMTPS id 721FD385843E for ; Sun, 13 Nov 2022 12:47:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 721FD385843E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nexgo.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1668343670; bh=uwey//F2QO3k0N1fEx5meDJ5epSpjj5LDHyhGFu5Trg=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID:User-Agent: Content-Type:From; b=RpNZblac3mNFAqRyvYzuiQFDEPGuKEsvrWlYqw/bLyC2llkr828qRwFoOFBqU8WjU hkR+OB5RS9MywL4lfXaNhsWZZD+DXiZvlSjhwQ4CqD78OVNwwYz54x9BqWK3QYi/kV nSpcs+ZjlTr5cDe4AYGtxcJtDCj7dB70FLkdLNKs= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr3.vodafonemail.de (Postfix) with ESMTPS id 4N9C061k8Fz1y8C for ; Sun, 13 Nov 2022 12:47:50 +0000 (UTC) Received: from Gertrud (p54a0cf01.dip0.t-ipconnect.de [84.160.207.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4N9C051h0Jz9s86 for ; Sun, 13 Nov 2022 12:47:46 +0000 (UTC) From: Achim Gratz To: cygwin-apps@cygwin.com Subject: Re: [Bug] setup regression #2 References: <87pmfn5o2j.fsf@Rainer.invalid> <0c8c757c-4f6b-3b49-5404-99353de48b1b@dronecode.org.uk> <877d1gd83r.fsf@Rainer.invalid> <3f6098ed-0b64-33f2-c8ca-36a92500adbb@dronecode.org.uk> <87pmf2p830.fsf@Rainer.invalid> <8a811ecf-38e7-a631-c09e-92ca4d439cc2@dronecode.org.uk> Date: Sun, 13 Nov 2022 13:47:38 +0100 In-Reply-To: <8a811ecf-38e7-a631-c09e-92ca4d439cc2@dronecode.org.uk> (Jon Turney's message of "Tue, 8 Nov 2022 16:21:44 +0000") Message-ID: <87iljjggwl.fsf@Rainer.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-purgate-type: clean X-purgate: clean X-purgate-size: 3064 X-purgate-ID: 155817::1668343669-A8FF84F8-F8162933/0/0 X-Spam-Status: No, score=-3029.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jon Turney writes: > On 08/10/2022 17:56, Achim Gratz wrote: >> I think that setup was essentially treating the install as "for this >> user only" since it was created and maintained by a script that can't >> affect that option and the fact it was also in group Adminsitroators >> didn't actually register until now. > > Yeah, that seems possible, since some of these changes fix what are > arguably bugs in how that works (i.e. I suspect that previously, even > when elevated, if only the registry key > HKEY_CURRENT_USER\\Software\\Cygwin\\setup\rootdir exists (and not the > same key under HKLM), we're going to install for "Just Me", > irrespective of what the UI says) I've checked some old logs and even though the install was identified as "system", there was no line "Changing gid to Administrators" for the main install until setup version 2.921. > I wrote some code for this option (attached), but I have a hard time > seeing how it's functionally different from using '-B/'--no-admin'. This option does nothing to prevent the use of Administrator group when the install is identified as "system" and those rights are actually available (which they are as the scripting needs those rights in other places). > So, I guess a question is, does running with that option work as > expected in your problematic instance? No, it does not, see above. The problem is actually a more knotty than you seem to think: prominently ca-certificates and man-db get their knickers in a twist when the group during post-install is different from the group of the installed files and I suspect some other packages will run into similar problems depending on how fussy they are with the group permissions. The symptom is that you see failures from chmod (for whatever reason "Invalid argument") when these programs try to swap the existing with the newly gerenated (temporary) files. In the case of man-db that results in the /var/cache/man/index.db file getting removed (and depending on the version the PID temporaries getting left in place), for update-ca-trust the mkstemp temporaries will be left over and the original files left in place. So all installs from before the change to setup are affected if the installation wasn't done via the GUI at least. I think it would be best to have an option to directly specify a desired group for both the installed files and running the post-install (which already must be in the user token). The default should be the primary group of the user doing the installation. I don't think the installation should be group-owned by "Administrators" on Windows. If anything it makes it much more difficult to administer the installation from within Cygwin as there doesn't seem to be a way to change to a different than the primary group for domain accounts yet. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada