1316410 - AWS policies taskcluster-level-X-sccache shouldn't have GetObjectAcl and PutObjectAcl

Status: RESOLVED WONTFIX

(Taskcluster :: Operations and Service Requests, task)

Description

[Jonas Finnemann Jensen (:jonasfj)]

I would prefer if policies: taskcluster-level-X-sccache
Didn't have GetObjectAcl and PutObjectAcl.

This breaks sccache, but works with sccache2.

Note: I've attached these policies to tc-auth so it can issues temporary credentials for these buckets.

@pmoore, grenade:
Is this something we can easily do. I prefer clients don't have to ability to make something public, if it's not supposed to be public.
If we want it public I propose a doing it with a bucket policy.

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

I think we need to relax this requirement and allow PutObjectAcl.  Prohibiting it breaks just about every tool that works with S3.  We never did get a good answer from the S3 engineers on the details of the IAM policy.  Maybe we could get their attention by exploiting one of their customers and collecting a bounty :)

Comment 2

[Rob Thijssen [:grenade (EET/UTC+0300)]]

i added the acl permissions to the policies in an effort to fix sccache (v1). since that's still broken (because of the task user directory name issue) and since sccache2 apparently doesn't need the acl rights, i wouldn't object to having them removed but i would coordinate with ted so he has a chance to test his symlink patches in bug 1187257 in case that does rely on the acl rights. currently there's nothing in the buckets to protect.

Comment 3

[Jonas Finnemann Jensen (:jonasfj)]

Okay, let's go back an reconsider this in some future when sscache v1 isn't in use anymore.

Comment 4

[(not currently active) Ted Mielczarek]

We enabled sccache2 on taskcluster, so this should no longer be an issue.

Comment 5

[Rob Thijssen [:grenade (EET/UTC+0300)]]

i have now removed GetObjectAcl and PutObjectAcl from the policies