Support for full mode Permissions

[visualphoenix]

Hi there,

One place where this code fails pjdfstest is round tripping chmod. Currently virtual.Permissions isnt wide enough to store the full mode set. Per your note on #226 - you expressed hesitation to add a new AttributesMaskMode, which makes sense - I was trying to avoid modifying Permissions itself, as I wasn't sure you'd be open to a different idea I had previously tried: extending type Permissions uint8 to uint16 or uint32.

Would this be something you'd be open to?

[EdSchouten]

I guess extending Permissions to uint16 would be acceptable. Though I think we should first do a full scan of the tree how Permissions is used right now. For example, NFSv4 opAccess() is currently implemented by calling Attributes.GetPermissions() and checking whether individual bits are set. This wouldn't necessarily work if we suddenly have owner, group, and other permissions. Because then the function needs to become aware whether the current caller is the owner or not.

[visualphoenix]

Yea... that was the problem I encountered when I tried it the first time and why I thought maybe you'd be more open to the attribute mode mask. I originally did a pass on uint16 and then thought hey why not just make it uint32 and set the top bit as a special flag to denote "full mode privs" vs the existing behavior where you squash away privs. idk, extending Permissions to uint16/uint32 as you said has some ramifications where you need to push the check squashing back down to the implementer... i have both of these ideas kinda sketched out and working - i can put up patches for both if you're interested?

[wenhbeatz]

Hi — are there plans to follow up on one of the implementation directions discussed here?

I am currently blocked by a mode-sensitive workload because restrictive Unix permissions do not round-trip through the virtual filesystem’s create/chmod/stat path. As a temporary workaround, I am placing the affected scratch data on a native vm filesystem, but we would prefer to remove that exception. (To be more specific, this is regarding Embedded PostgreSQL -- which creates a unique temporary PGDATA directory inside the Bazel test temporary tree. Under remote execution, that tree is served by Buildbarn FUSE. PostgreSQL requires its data directory to retain a restrictive Unix mode. FUSE cannot represent owner, group, and other permission bits separately, so the requested mode is collapsed, and then rejection)

Is the preferred upstream direction now uint16 with caller-aware owner/group/other access checks, or a separate/tagged full-mode representation that preserves existing collapsed semantics?

I'd be interested in putting in a patch as it solves this problem for me

[visualphoenix]

Sure - I have two different kinds of implementations for this that i've been using locally. I've been on vacation but I can put something up later tonight or tomorrow.