Explicit Ownership set when installed into Program Files?

[byjrack]

So been trying to pivot as many products to User based installs to better align to MSIX standards for our single user machines.

In the environment there are those w Git installed for machine and as user. I noticed some oddness with those upgrading from a machine install where I would expect a complete failure, but getting mostly success. So an install as /CURRENTUSER and a non-Admin context will be able to almost upgrade. You will get a UAC that you decline and then the upgrade continues mostly unabated (other than dev/fd binar which gives an Access Denied 5).

Was there a reason the ownership was changed to a single user if you are installing in a machine wide context?

[byjrack]

Another oddity it creates is a dual entry in Add/Remove (i.e. Git (Current User)), but if you uninstall either it impacts the same install. Minor papercut stuff, but just trying to drive a bit of consistency in the environment.

[dscho]

Git for Windows only really supports system-wide installations. The user-wide installation is not really supported.

[dscho]

No, this has nothing to do with PATH and everything to do with "the system config" being a globally unique path, even across users.

But on Windows, there is no such thing as a /etc/ folder that is the place to put system-wide configuration. So there is C:\Program Files\Git\etc\gitconfig, and that is the system config.

Except if you have a user-wide installation, then it is somewhere in %LOCALAPPDATA%\Programs\Git and neither Visual Studio nor GitHub Desktop nor Eclipse will have any idea that you configured, say, core.autocrlf=input in that location.

That is the kind of problem I am talking about.

[byjrack]

Yup I follow you on the system side of the equation. And 100% get that --system for a User scoped install is sort of a conflict as by definition it's not a system-wide thing. We have mostly single user machines in our distributed fleet so "machine-wide" with gated configs behind UAC is more friction than value. I might say if I had machine wide I don't want folks tweaking those configs so the ACL ownership change actually disables any control over those "top down" configs.

Our users rarely use --system and live mostly out of --global. I get that in User scoped the "system" is in their profile under %LOCALAPPDATA%/Programs/Git/etc, but beyond the install config folks don't tend to tweak those settings often. Hypothetically you could say that if you wanted a common file system location that all users have read/write to you could use C:\Users\Public. That doesn't duplicate /etc/gitconfig or /usr/local/etc/gitconfig which would require sudo.

I never have had an issue with tools failing to source configs as they seem to use the standard union view, but you have the history, context, and experience.

Is there an option to suppress the ownership change for machine-scoped installs? If not I can probably reset the ACL post-install as part of the calling script under System. Rather be consistent with policy and standard conventions even if it means extra steps for associates to update their install. I still would value an "officially" supported User scoped config personally as that is the direction we are going for most things even if it means "--system" isn't really machine-wide.

[dscho]

I cannot answer those questions because I have zero bandwidth to take care of user-specific installations: these are currently outside of the many, many things I support.

Feel free to work on addressing these issues you see, as long as they do not impact system-wide installations negatively. I also invite you to scour the code defining how the installer is built to find out where that ACL is set; I am no aware of any custom code doing that, but it is quite possible that this is done as part of the git.exe config calls (which are run in elevated mode). Finally, I am not aware of any way to let InnoSetup run in elevated mode depending on a command-line option. In other words, I do not think there is a way to create an installer that runs in elevated mode when doing a system-wide installation, and not in elevated mode when only installing for the current user. I might be wrong on that, and would be delighted if you found a way.

[byjrack]

Yup more for awareness than anything.

In-box directive for user is the /CURRENTUSER or /ALLUSERS flag for machine from my testing. Rather than check for admin it's more an explicit scope similar to the winget machine/user scope directive. The self-elevate function is still important because if you specify machine, but lack access you would still need that UAC token. I think where the PrivilegesRequired conditional is you could check for explicit command line params, but I am sure that would cascade into other dialogs and be a much bigger change.

And will check around the inno files to see if I can figure out where that ACL is coming from. Could just be the context of the installer at runtime so as I shift to the portal context and initiator it may self resolve.

[rimrul]

No, this has nothing to do with PATH and everything to do with "the system config" being a globally unique path, even across users.

But on Windows, there is no such thing as a /etc/ folder that is the place to put system-wide configuration. So there is C:\Program Files\Git\etc\gitconfig, and that is the system config.

Except if you have a user-wide installation, then it is somewhere in %LOCALAPPDATA%\Programs\Git and neither Visual Studio nor GitHub Desktop nor Eclipse will have any idea that you configured, say, core.autocrlf=input in that location.

There is currently a patch series on the mailing list that could help reduce these problems in future versions of Git: https://lore.kernel.org/git/[email protected]/T/#t