Pinning semantics are different than on Linux

Describe the bug

As far as I can tell pinning is implemented in the driver, by keeping a global hash table mapping strings to handles. Removing a pin is calling the same function with INVALID_HANDLE and the string you want to unpin.

• The string is treated as being utf8 encoded. Filesystem paths on Linux are not required to be utf8. They are just a bag of bytes (without any 0 in it though).
• Any application / user can unpin any handle. On Linux unpinning is subject to file access controls, which usually means that you have to be the same user. This is bad when an application relies on pinning to ensure that enforcement programs stay active during a restart for example.

OS information

No response

Steps taken to reproduce bug

Roughly (this is just based on reading the source code):

• Pin "abcd" from app A
• Unpin "abcd" from app B

Expected behavior

The call to unpin from app B should fail.

Actual outcome

The call to unpin from app B doesn't fail.

Additional details

No response

Start by tracing the driver’s pin and unpin implementation, especially the global string-to-handle table described in the issue. Compare its path encoding and authorization behavior with Linux semantics; done means non-owners cannot unpin another application’s handle and filesystem paths are not incorrectly restricted to UTF-8.