Files managed with the adapter are not fully manageable in cloud console about flysystem-google-cloud-storage HOT 14 CLOSED

I can confirm the issue exists - we have the same problem. We've just never needed to do anything via the console, outside of the API.

I don't have the time to mess around with this right now, but it might have something to do with the predefinedAcl we set when creating an object -> https://github.com/Superbalist/flysystem-google-storage/blob/master/src/GoogleStorageAdapter.php#L122 but this is just a hunch.

from flysystem-google-cloud-storage.

Alright - thank you for the hint and the confirmation, I will investigate it myself when the time allows it.

from flysystem-google-cloud-storage.

@figmutant - can you squiz at this, thanks.

from flysystem-google-cloud-storage.

Note: I think it's about the ownership (as per https://cloud.google.com/storage/docs/access-control#scopes-and-permissions).

If only the service account is set as owner, only it could operate on it.

Reading the ACL with gsutil results in a failure:

$ gsutil acl get gs://bucket/public.gif
AccessDeniedException: Access denied. Please ensure you have OWNER permission on gs://bucket/public.gif.

from flysystem-google-cloud-storage.

You were absolutely right about the ownership with predefinedAcl (https://cloud.google.com/storage/docs/json_api/v1/objects/insert#predefinedAcl).

There's a lot more options than just private and publicRead options - but the publicRead option implies exactly that: The owner (the service account) can do all operations, and the project members have read access. All is fine until you need to modify the file from another service account (or user account).

I therefore propose 2 things:

1. The default predefined ACL should be bucketOwnerFullControl and should be configurable for more sophisticated projects, which require isolation of service accounts. This setting allows the project members to access the files from the console and any other tool (gsutil for example).

2. When the file is requested to be public (AdapterInterface::VISIBILITY_PUBLIC) from flysystem, an additional ACL entry should be created for the object:

   $acl = new Google_Service_Storage_ObjectAccessControl();
   $acl->setEntity('allUsers');
   $acl->setRole('READER');

   That's exactly what happens when you use the cloud console to make files public.

from flysystem-google-cloud-storage.

Thanks.

To confirm:

1. When an object is created, it should always be given a predefinedAcl of bucketOwnerFullControl. If the object is uploaded with visibility set to public, a 2nd call needs to be made immediately after creation to change visibility and create that allUsers - READER ACL.
2. If the visibility of a file is changed from private to public, the allUsers - READER ACL needs to be created.
3. If the visibility of a file changes from public to private, we need to find that ACL entry and delete it.

from flysystem-google-cloud-storage.

Correct (as far as my statements from above). Just now i am experimenting with the api and experience that the service account loses control of the objects' ACL when bucketOwnerFullControl it used.

This has the consequence that the service account cannot add the READER role for the allUsers entity. Seems we need a three-legged operation.

1. Service account gains role OWNER on object creation and needs to keep it

2. Bucket owners need to be added to the ACL with OWNER role. To accomplish this, a Google_Service_Storage_ObjectAccessControl object with entity owners-$numericprojectId and role OWNER needs to be inserted:

   $publicAcl = new \Google_Service_Storage_ObjectAccessControl();
   $publicAcl->setEntity('owners-$numericprojectId');
   $publicAcl->setRole('OWNER');
   $this->service->objectAccessControls->insert($this->bucket, $path, $publicAcl);

3. (optional) insert another Google_Service_Storage_ObjectAccessControl with allUsers entity and READER role to allow public access

   $publicAcl = new \Google_Service_Storage_ObjectAccessControl();
   $publicAcl->setEntity('allUsers');
   $publicAcl->setRole('READER');
   $this->service->objectAccessControls->insert($this->bucket, $path, $publicAcl);

Open questions:

• where do we get the numerical project id from?
• what happens if an object is moved? Do the ACL entries for the object path get moved as well?

Phew. Sorry for that many messages, but I had to chop through the ACL model.

from flysystem-google-cloud-storage.

Referring to the documentation (https://cloud.google.com/storage/docs/access-control?hl=en):

"By default, anyone who has OWNER permission or WRITER permission on a bucket can upload objects into that bucket. When you upload an object, you can provide a predefined ACL or not specify an ACL at all. If you don't specify an ACL, Google Cloud Storage applies the bucket's default object ACL to the object. Every bucket has a default object ACL and this ACL is applied to all objects uploaded to that bucket without a predefined ACL or an ACL specified in the request (JSON API only). The initial value for the default object ACL of every bucket is projectPrivate."

What if we didn't specify any predefined ACL at object creation. All objects should take the default value (projectPrivate if not manually changed).

If a user changes visibility from PRIVATE to PUBLIC, the allUsers - READER ACL is created.
If a user changes visibility from PUBLIC to PRFIVATE, that ACL is searched for and if found, deleted.

Would this not work around the project / service account / user permissions issue.

If an object is moved, I seem to recall the ACL from the source object not copying across. You can specify a destinationPredefinedAcl though - https://cloud.google.com/storage/docs/json_api/v1/objects/copy
See https://github.com/Superbalist/flysystem-google-storage/blob/master/src/GoogleStorageAdapter.php#L165
There's no way to really move() via their API, so we do a copy and delete.

from flysystem-google-cloud-storage.

Tried it and found another conceptual flaw: The service account has no ownership on the object anymore, when the file is created without a predefined ACL.

This prevents the service account from modifying the ACL afterwards.

from flysystem-google-cloud-storage.

I have just encountered this issue. Using the latest version form Composer.

from flysystem-google-cloud-storage.

Yep. This won't change until they tag a new version. Use dev-master if you need the version with the fixes.

from flysystem-google-cloud-storage.

Yea, just figured that out. Hope they flag a new latest version soon.

EDIT - So I'm using dev-master, and used elFinder to make a new, blank text file in my GCS bucket. It can now been viewed, but I am unable to move it, or edit it.

from flysystem-google-cloud-storage.

Apologies for the delay, this is fixed in https://github.com/Superbalist/flysystem-google-storage/releases/tag/1.0.1

from flysystem-google-cloud-storage.

Excellent, thank you!

from flysystem-google-cloud-storage.