Revisit how we handle imported and exported files' consistency with permissions and UID/GIDs #1413
Description
See original issue on GitLab
In GitLab by [Gitlab user @BenjaminSchubert] on Dec 4, 2020, 12:46
We used to use umasks to configure the permissions of the files we import and export in BuildStream.
This got broken for some cases when moving to Buildbox-casd, and has different behaviors now depending on whether buildbox-fuse is used or not.
!1982 removes the handling of the umasks completely, as it is not much worse than before, and we need a better, higher level solution for source consistency.
From https://gitlab.com/BuildStream/buildstream/-/merge_requests/1982#note_460499065, we have a general story that:
- User decides to leave something unspecified about the execution environment
- The execution environment is not required to support that something, but if it supports that something, it will do something consistent (like defaulting to UID/GID 0 even if the user didnt hard require that)
- User decides to specify a specific attribute of the execution environment, like the process UID or GID
- In this case the sandbox implementation (local or remote) will either support the specified attribute, or an error will be delivered to the master build log informing the user that no execution environment was available to support the required environment
I think that this counts as a situation of possible variance, and perhaps the right API for this is to have
SandboxConfigentries to support such, for instance the user can specify the required umask for staging files in an execution environment where files are otherwise either 0644 or 0755. If it is left unspecified, then it can be handled with the hardlinks approach, otherwise another environment which supports this invariance is required (possibly fuse on linux).
We therefore need to decide on what interface we want to give to users and where in the stack it is best implemented.