It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable not touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If such a change is outside the scope of this bug, making `/builds/tooltool_cache` world readable would be a simple way to overcome the issue, but it isn't as secure as using a cache, which guards the cache with taskcluster scopes.
Bug 1561956 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If such a change is outside the scope of this bug, making `/builds/tooltool_cache` world readable would be a simple way to overcome the issue, but it isn't as secure as using a cache, which guards the cache with taskcluster scopes.
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions.
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions. --- Update: on reflection I see there are still some open bugs regarding caches that could possibly bite us, perhaps better to just make `/builds/tooltool_cache` world readable/writable for now.
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions. ----- Update: on reflection I see there are still some open bugs regarding caches that could possibly bite us, perhaps better to just make `/builds/tooltool_cache` world readable/writable for now.
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions. ----- Update: on reflection I see there are still some open bugs relating to generic-worker writable directory caches that could possibly bite us, perhaps better to just make `/builds/tooltool_cache` world readable/writable for now. Some of these bugs might not be relevant (e.g. Windows only, or solved but not updated) but it would be best for us to review them before we use the same feature on macOS, in case macOS shares any of the same issues. * bug 1290536 * bug 1433854 * bug 1479889 * bug 1526311 * bug 1527313
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions. ----- Update: on reflection I see there are still some open bugs relating to generic-worker writable directory caches that could possibly bite us, perhaps better to just make `/builds/tooltool_cache` world readable/writable for now. Some of these bugs might not be relevant (e.g. Windows only, or solved but not updated) but it would be best for us to review them before we use the same feature on macOS, in case macOS shares any of the same issues (and in case it would be good to resolve the open issues). * bug 1290536 * bug 1433854 * bug 1479889 * bug 1526311 * bug 1527313
It looks like a lot of the failures are permissions issues with reading/writing `/builds/tooltool_cache`. This is expected - each task runs as a different user, so unless `/builds/tooltool_cache` is world readable/writable, I'd expect to see that. It would be preferable for tasks not to touch files outside the home directory of the task user; in other words for `/builds/tooltool_cache` not to exist but tasks to mount a [writable directory cache](https://github.com/taskcluster/generic-worker/blob/14d7d4559113715ca2a23a4a2900690a94307673/multiuser_posix.yml#L255-L304) into the task directory containing the tooltool cache. If changing the location of the tooltool cache is deemed to be outside the scope of this bug, making `/builds/tooltool_cache` world readable/writable would be a simple way to overcome the issue, but this solution comes with the caveat that it isn't as secure as using a writable directory cache, which guards the cache with taskcluster scopes, meaning only tasks with the required scopes can modify the cache, not any task that runs on the worker type. This is somewhat mitigated by being able to restrict which tasks can run on the worker type, but a writable directory cache would still be better, if only for the fact it is more explicit about its intentions. ----- Update: on reflection I see there are still some open bugs relating to generic-worker writable directory caches that could possibly bite us, perhaps better to just make `/builds/tooltool_cache` world readable/writable for now. Some of these bugs might not be relevant (e.g. Windows only, or solved but not updated) but it would be best for us to review them before we use the same feature on macOS, in case macOS shares any of the same issues (and in any case it would be good for us to resolve these open bugs). * bug 1290536 * bug 1433854 * bug 1479889 * bug 1526311 * bug 1527313