Pinning semantics are different than on Linux

[lmb]

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

[shankarseal]

Right now since only administrators have privilege to pinning APIs, there is no real security boundary between two applications, and the current behavior is by design.

This is a feature request to apply per-user ACL for pinned objects.