BuildStream-Migration-Bot opened a new issue #1413: URL: https://github.com/apache/buildstream/issues/1413
[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/1413) In GitLab by [[Gitlab user @BenjaminSchubert]](https://gitlab.com/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 `SandboxConfig` entries 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. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
