-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[7.0] Fix session-local named mutex compat issue #90343
[7.0] Fix session-local named mutex compat issue #90343
Conversation
Tagging subscribers to this area: @mangod9 Issue Details
Customer ImpactFiles 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 TestingVerified compatibility between unfixed and fixed versions of the runtime with using session-local named mutexes RiskLow. 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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
approved. we will take for consideration in 7.0.x
Don't forget to add the |
@kouvel can you please retarget the PR to the |
Retargeted to |
Thank you for fixing this! This will clear up a lot of CI failures. |
c0deb4f
into
dotnet:release/7.0-staging
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 being reverted (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.