Re: [Bug] setup regression #2

[Christian Franke <Christian.Franke@t-online.de>]

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