From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout02.t-online.de (mailout02.t-online.de [194.25.134.17]) by sourceware.org (Postfix) with ESMTPS id B3E943858D1E for ; Wed, 30 Nov 2022 21:22:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B3E943858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=t-online.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=t-online.de Received: from fwd88.dcpf.telekom.de (fwd88.aul.t-online.de [10.223.144.114]) by mailout02.t-online.de (Postfix) with SMTP id 772E418553; Wed, 30 Nov 2022 22:22:41 +0100 (CET) Received: from [192.168.2.101] ([87.187.32.177]) by fwd88.t-online.de with (TLSv1.3:TLS_AES_256_GCM_SHA384 encrypted) esmtp id 1p0UXP-1vSNGq0; Wed, 30 Nov 2022 22:22:39 +0100 Subject: Re: [Bug] setup regression #2 To: Jon Turney , "cygwin-apps@cygwin.com" 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> <87iljjggwl.fsf@Rainer.invalid> <87fsedla3u.fsf@Rainer.invalid> From: Christian Franke Message-ID: <16c0bdb4-00bb-3f96-7940-2273b6f0b82b@t-online.de> Date: Wed, 30 Nov 2022 22:22:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 SeaMonkey/2.53.14 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TOI-EXPURGATEID: 150726::1669843359-E30B0E65-C0C3CE42/0/0 CLEAN NORMAL X-TOI-MSGID: 2d2b896e-6d59-4811-8dbc-c01413bf9638 X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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 wrote: > On 20/11/2022 19:05, Achim Gratz wrote: >> Jon Turney writes: >>> I believe that the intent of the code in setup is that there should >>> only be two modes: >>> >>> USER: install "for me", with the users primary group >> >> As I understand it, the intention here was that the user can have a >> "single user installation" in a place that they have access to (say, >> their home directory) while they have no permission in one of the usual >> places.  In a setup where that place is a certain type of share the user >> will not be able to change the group the files are owned by anyway >> (standard NetApp CIFS shares are set up this way) and it may not be the >> users primary group. >> >>> SYSTEM: install "for everyone", with the administrators primary group >>> (only permitted if you are an administrator) >> >> I don't see why the fact the installation is meant to be used by >> multiple users means that the install must be owned by group >> Administrators.  I'm not sure this is a good idea on Windows anyway, at >> least when you don't put extra (inheritable) DACL on the install >> folder. > > Christian, > > Maybe you can offer your opinion here, since you seem to have the > opposite, or at least a different, point of view. Anything installed with "All Users" option should IMO be protected against modifications by any regular non-elevated user. This is not the case if the RID=513 group ("HOST\None", "DOMAIN\Domain-Users") is used. Many upstream projects install directories and files with permissions like 0664, 0775, 0660 or 0770. This is safe when the group is "root". On current Cygwin, all users have R/W access regardless of the "other" permission bits. Try for example: find /usr/share ! -type l -perm -020 -ls (~4000 hits on my installation) Using the administrators group as discussed here would solve this but apparently introduces interesting new permission problems with some packages. Could these possibly be solved by the maintainers of the affected packages? An alternative may be: Keep the group as is, but prevent using above permissions as far as possible. For new packages, this could possibly be done with an enhancement of cygport. But I'm sure that there will also be subtle cases where these modified permissions break things. Cygport could allow to opt-out then. Ideally the protection should also be effective for the non-elevated user who runs setup elevated. This is automatically the case for typical installers because Windows changes TokenOwner to administrators group if run elevated. That's why I provided https://sourceware.org/pipermail/cygwin-apps/2022-August/042221.html