You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.NET stack creates many temporary folder as part of the command execution. In many cases, if the command is running under sudo, the temp directory will be shared with the non-sudo user. If files or folders are shared between sudo and non sudo command. And if the command is first run under sudo, the folder would be default set to ROOT user access only. So then next command run without sudo will not be able to access.
While we have this behavior since 1.0. There are not many scenarios require .NET run under sudo. This issue become significate when we integrate with mac installer for workload install. It need to be run under sudo. We decided to override $HOME directory to /tmp/dotnet_sudo_home/ when we detect the command is running under sudo. And therefor "simulate" the behavior sudo -i. So sudo vs non sudo command won't share the same directory
long term solution
Not fully discussed. One direction is to have an file system abstraction across the stack.
The text was updated successfully, but these errors were encountered:
Issues like
#19823
#19523
.NET stack creates many temporary folder as part of the command execution. In many cases, if the command is running under sudo, the temp directory will be shared with the non-sudo user. If files or folders are shared between sudo and non sudo command. And if the command is first run under sudo, the folder would be default set to ROOT user access only. So then next command run without sudo will not be able to access.
Most of these temporary folder use $HOME as base, while sudo on mac does not change $HOME when run under sudo. https://unix.stackexchange.com/a/91572
Temp folder potentially have the issues:
runtime
sdk
nuget
template engine
short term solution
While we have this behavior since 1.0. There are not many scenarios require .NET run under sudo. This issue become significate when we integrate with mac installer for workload install. It need to be run under sudo. We decided to override $HOME directory to
/tmp/dotnet_sudo_home/
when we detect the command is running under sudo. And therefor "simulate" the behaviorsudo -i
. So sudo vs non sudo command won't share the same directorylong term solution
Not fully discussed. One direction is to have an file system abstraction across the stack.
The text was updated successfully, but these errors were encountered: