Fix session-local named mutex compat issue #90342
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Customer Impact
Files relevant to session-local named mutexes go into a session directory with the session ID in its name. Previously, the session directory's permissions were restricted to the creating user. When a session ID gets reused by a different user, a .NET process that tries to use a session-local named mutex fails with an exception because it's unable to create or access files under the session directory.
Regression?
Yes, from the PR mentioned in the first commit
Testing
Verified compatibility between unfixed and fixed versions of the runtime with using session-local named mutexes
Risk
Low. The compat issue may not be fully fixed in all cases since restricted permissions are involved, though based on the amount of feedback we've gotten about the compat issue, it seems likely that most cases would be resolved by updating the runtime to include this fix. There are one-time workarounds for remaining cases, such as updating all used runtime versions to include the fix, restarting the machine if the OS has a cleanup policy for
/tmp/
upon restart, or deleting/tmp/.dotnet/shm/
and/tmp/.dotnet/lockfiles/
when there are no .NET processes running.