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
