[6.0] Fix session-local named mutex compat issue

[kouvel]

• Port of Fix session-local named mutex compat issue #90342
• 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

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.

[ghost]

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

Issue Details

---

• Port of Fix session-local named mutex compat issue #90342
• 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:	6.0.x

[jeffschwMSFT]

approved. we will take for consideration in 6.0.x

[carlossanlop]

FYI today is code complete for the September Release. Since this has not been approved by Tactics, it'll have to wait until the October Release.

[carlossanlop]

FYI I retargeted the branch to release/6.0-staging. Will merge once the CI is done.