Rejet ACL de l'API S3-Compatible de GCS
Problème
Les appels S3 put_object échouent avec InvalidArgument lors du ciblage de Google Cloud Storage via son API S3-compatible, bien qu'ils fonctionnent correctement avec MinIO ou AWS S3.
Contexte / Conditions de déclenchement
- Utilisation de
aws-sdk-s3(Rust) ou tout SDK S3 avec endpoint GCS AWS_ENDPOINT=https://storage.googleapis.com- Erreur :
Error { code: "InvalidArgument", message: "Invalid argument." } - La trace de pile affiche
S3BlobStore::put_tempou une opération put S3 similaire - Le bucket GCS a l'accès uniforme au niveau du bucket activé (par défaut GCS)
Solution
Supprimez ObjectCannedAcl::PublicRead des appels put_object lors de l'utilisation de GCS :
// AVANT (échoue sur GCS avec accès uniforme au niveau du bucket)
self.client
.put_object()
.body(body)
.bucket(&self.s3_bucket)
.key(key)
.acl(ObjectCannedAcl::PublicRead) // Ceci provoque InvalidArgument
.send()
.await?;
// APRÈS (fonctionne avec GCS)
self.client
.put_object()
.body(body)
.bucket(&self.s3_bucket)
.key(key)
// Supprimez .acl() — utilisez plutôt la politique IAM au niveau du bucket
.send()
.await?;
Pour l'accès en lecture publique, configurez plutôt la politique IAM du bucket :
gsutil iam ch allUsers:objectViewer gs://YOUR_BUCKET
Ou désactivez l'accès uniforme au niveau du bucket (non recommandé) :
gsutil ubla set off gs://YOUR_BUCKET
Vérification
Après suppression de l'appel .acl(), l'upload devrait réussir :
curl -X POST "$PDS_URL/xrpc/com.atproto.repo.uploadBlob" \
-H "Authorization: Bearer $JWT" \
-H "Content-Type: video/mp4" \
--data-binary @test.mp4
Notes
- L'accès uniforme au niveau du bucket de GCS est le par défaut depuis 2023
- L'appel
copy_objectdansmove_object()utilise aussi.acl(PublicRead)et échouera - Cela affecte le stockage blob rsky-pds :
rsky-pds/src/actor_store/aws/s3.rslignes 69, 97, 212 - MinIO n'applique pas cette restriction, donc le dev local fonctionne mais la GCS de production échoue
- Le même problème s'applique aux méthodes
put_permanent()etmove_object()