Add support for named synchronization objects that are restricted to the creating user (where applicable)

[kouvel]

• By default, named synchronization objects (mutexes, semaphores, and events) are usable by multiple users. This could be problematic on systems where untrusted users may run code.
• It would be useful to provide support for named synchronization objects that are restricted to the user that created the synchronization object. For instance, in scenarios where the user would like to protect with a mutex a user-specific resource. Such scenarios already exist and are likely common. On Windows, there are Windows-specific APIs that can be used, but the code would not be portable, and on Unixes there is no alternative. This could be done in various ways, like a new prefix in the name, new API, etc., in a way that works on all OSes.
• On Unixes, only named mutexes are supported, so providing a user-specific named mutex would be sufficient

[ghost]

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

Issue Details

---

- By default, named synchronization objects (mutexes, semaphores, and events) are usable by multiple users. This could be problematic on systems where untrusted users may run code. - It would be useful to provide support for named synchronization objects that are restricted to the user that created the synchronization object. For instance, in scenarios where the user would like to protect with a mutex a user-specific resource. Such scenarios already exist and are likely common. On Windows, there are Windows-specific APIs that can be used, but the code would not be portable, and on Unixes there is no alternative. This could be done in various ways, like a new prefix in the name, new API, etc., in a way that works on all OSes. - On Unixes, only named mutexes are supported, so providing a user-specific named mutex would be sufficient

Author:	kouvel
Assignees:	kouvel
Labels:	`area-System.Threading`
Milestone:	9.0.0

[fbrosseau]

in netcore, named pipes added the PipeOptions.CurrentUserOnly for this purpose (in replacement of netfx having the nightmarish full API for setting up ACLs). CurrentUserOnly is high-level enough that it allows the runtime to implement this concept the best way possible for each platform.

If I use named kernel objects, I would not be expecting the runtime to customize my name in any way (at least on Windows). The other program using my object may very well not be dotnet code. So at least for Windows, I would expect the implementation to just be setting up ACLs on my behalf.

[kouvel]

If I use named kernel objects, I would not be expecting the runtime to customize my name in any way (at least on Windows). The other program using my object may very well not be dotnet code. So at least for Windows, I would expect the implementation to just be setting up ACLs on my behalf.

That's what I was thinking as well. Adding something like PipeOptions.CurrentUserOnly would work too, regarding adding a new prefix to the name, I intended for it to just be a way of conveying that it is to be restricted to the creating user, the prefix doesn't have to actually be in the underlying name. Another possibility is to add some user prefix to the real name of the named mutex (in a clearly documented way) to help give those a somewhat different namespace, but that's probably not too important, and it complicates opening an existing user-specific mutex that doesn't have the prefix.

I think a new API approach may be better, as it would help to incentivize people to use user-specific named mutexes where possible (along with having a warning for all-user named mutexes), and it may even be possible in the future to deprecate the current APIs in favor of the one with an enum.