Jon Turney wrote:
On 06/07/2022 08:14, Christian Franke wrote:
If an installer is run elevated, the installed files will be
typically owned by the local administrator (or in some cases SYSTEM
or TrustedInstaller) instead of the current user. This is not the
case for a Cygwin "All Users" installation. The files are then not
protected from
... instead the files are owned by the user running setup?
Yes, because the TokenUser is unconditionally copied to TokenOwner. Some
research with 'git blame' shows that many parts of the related code are
from the early days of UAC and elevated processes (Vista 2006, Win7
2009). Things may have changed since then, I don't know (or remember).
If a process is run elevated, Windows keeps TokenUser unchanged but sets
the TokenOwner to local administrator. The --chown-admin option simply
keeps this as is, so no actual chown() is needed later. The
TokenPrimaryGroup is not changed by Windows, therefore --chown-admin
calls setAdminGroup() to mimic the usual "root root" ownership.
Typical simple installers leave everything as is, so the installed files
are owned by local adminstrator and group "None" (S-1-5-21-*-513), see
'ls -l "$PROGRAMFILES"'.
accidental changes by this user.
The attached patch adds an experimental --chown-admin option which
allows (new) installations owned by local administrator user and group.
Thanks for the patch, but...
A drawback is that files generated by postinstall scripts are still
owned by current user + "None" group. It should be possible to fix
this with some perpetual preremove+postinstall scripts.
I also don't know whether this may break some postinstall scripts.
BTW: 'nt_sec.setDefaultSecurity (isAdmin)' is never called with
'isAdmin==true' as 'root_scope' is always 0.
root_scope is set later, by the "Install For" option on the "Select
Root Install Directory" page.
To me, this looks like a (very long standing) bug that we shouldn't be
calling setAdminGroup() here, but after root_scope has been set.
If this bug is very old, I'm not sure whether this should be fixed.
Setting admin group to files which are owned "only" by current user is
possibly not very effective.
