Skip to content
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

Fix session-local named mutex compat issue #90342

Merged
merged 2 commits into from
Aug 11, 2023
Merged

Conversation

kouvel
Copy link
Member

@kouvel kouvel commented Aug 10, 2023

  • A previous change that was serviced back changed session-local named mutexes to be user-specific by restricting the permissions of the session directories and files under them, and adding the sticky bit to some directoires. A compat issue arose from that change, as the session directories have the session ID in their name and session IDs can be reused between different users. The current plan that we have discussed is to revert the change and service back the revert, which also restores the intended behavior, and offer user-specific mutexes as a new feature in a future .NET that would satisfy some user scenarios in a better way.
  • This PR reverts the previous change (first commit) and restores one change from the previous change (second commit) to improve backward compatibility due to differences in permissions for session directories before and after the change
  • Fixes IOException running NuGet-Migrations during tests in dotnet CLI first run #80619

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.

@kouvel kouvel added this to the 8.0.0 milestone Aug 10, 2023
@kouvel kouvel requested review from janvorli and mangod9 August 10, 2023 21:17
@kouvel kouvel self-assigned this Aug 10, 2023
@ghost
Copy link

ghost commented Aug 10, 2023

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details
  • A previous change that was serviced back changed session-local named mutexes to be user-specific by restricting the permissions of the session directories and files under them, and adding the sticky bit to some directoires. A compat issue arose from that change, as the session directories have the session ID in their name and session IDs can be reused between different users. The current plan that we have discussed is to revert the change and service back the revert, which also restores the intended behavior, and offer user-specific mutexes as a new feature in a future .NET that would satisfy some user scenarios in a better way.
  • This PR reverts the previous change (first commit) and restores one change from the previous change (second commit) to improve backward compatibility due to differences in permissions for session directories before and after the change
  • Fixes Restrict named mutex files permissions #78106

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.

Author: kouvel
Assignees: kouvel
Labels:

area-System.Threading

Milestone: 8.0.0

@kouvel kouvel merged commit 1c4e4c1 into dotnet:main Aug 11, 2023
@kouvel kouvel deleted the NamedMutexFix branch August 11, 2023 21:34
@ghost ghost locked as resolved and limited conversation to collaborators Sep 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IOException running NuGet-Migrations during tests in dotnet CLI first run
2 participants