[Proposal] Add /Library/Preferences/dotnet/Settings.plist to Change PKG Installer to Append to PATH #118004
Description
Change Goal
The 'admin' or 'trusted' installs set the 'System' 'PATH' environment variable. This is true for the pkg installer and the Windows installer. We are making a change to enable a policy which disables that behavior. This proposal is about the Mac installs only.
Change
Enable a new file: /Library/Preferences/dotnet/Settings.plist
The dotnet folder doesn't exist yet, but Xamarin and Maui have the same file (under their name, not dotnet.) The library folder is a system-level folder where application configuration tends to go on Mac, based on my research. Note that I am not a 'Mac' developer by trade so if I am wrong or this can be done better please let me know.
The pkg installer should now check that file. Inside it lives the following to disable the installer from overwriting the entire path:
ConfigureHostPath=0 (This is the same name as the windows registry key value which will be proposed separately and is being worked on by @joeloff)
which we can read by using:
defaults read /dotnet/Settings.plist ConfigureHostPath
If and only if this is set to 0 should we do this. Nothing is going to set that file for now.
defaults has been around since mac os 10.0 which is from 2001: https://developer.apple.com/documentation/foundation/userdefaults
This would happen around here:
(Arcade owns the pkg build MSBuild logic, which seems to not manipulate the Path in other ways, as to my knowledge pkgbuild does not build a pkg which sets the PATH: https://github.com/dotnet/arcade/blob/2586309f3f8553152e2d1d54612e9199975f9cd4/src/Microsoft.DotNet.Build.Tasks.Installers/build/installer.build.targets#L429C1-L430C1). Under the above condition, the path would be appended to as a new line to the file instead of using tee to overwrite the file.I am proposing this over a 'random sentinel file' to try to adhere to the OS schema and standard. There are several of these which exist today. This proposal is not about consolidating them, however, this could open up that possibility.
Motivation
The reason for the policy change is because of a project proposal to light up scenarios like 'dnvm', 'nvm' or 'rustUp' but for dotnet. This context uses a user path to manage installs. With the current scenario, any admin install would break such a feature because it would override the PATH. That may happen automatically or by user intervention to install an admin level SDK. Of course, we would enable the scenario to revert to the admin behavior. Please see dotnet/designs#335 for more. Please don't use this thread as a discussion forum for the product idea, and leave that feedback on the PM product framing proposal instead, which @baronfel may provide, as it is not yet available on GitHub.
On Windows this will be done in the registry, which is an admin protected location. It is essential that this behavior is not on by default and is block-able by IT Administrators.
On Mac, the path is managed by the path_helper. This searches the specified location of etc/paths.d/ which is owned by root and is not world-writeable. This is equivalent to a 'system path.'
To address the following: Once the system PATH is no longer managed by an elevated and trusted installer, a compromised machine can be targeted to use a compromised toolchain. The same is true for runtimes on the PATH managed by dotnet, which would normally be in a protected location, would now cause FDD apps to use a user-local runtime if available. Note that we have security approval for this path forward and we can speak about this offline. That scenario is not enabled by this change, as elevation or root privilege would be required to set this flag, considering /Library/Preferences/ is owned by root and not world-writeable. If root access is already compromised then all bets are off, but it is very important that the expectation of file permissions of /Library/Preferences being owned and only writeable via root holds true.
This feature will not be used by an official product in .NET 10. However, since the pkg uses tee to overwrite the PATH, we want to service installers to behave properly with tools such as dnvm, and or an official subsidiary once it arrives in presumably .NET 11. PKG Installers for older versions of dotnet (unless serviced) would still cause this issue. On Windows, this is not the case as long as a newer installer is present with the change.