Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

s3: permissions and metadata change #7422

Closed
cyberduck opened this issue Sep 1, 2013 · 7 comments
Closed

s3: permissions and metadata change #7422

cyberduck opened this issue Sep 1, 2013 · 7 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Sep 1, 2013

a304470 created the issue

Since some time permissions and metada have changed.

  • permissions now:
Everyone                  READ
http://acs.amozonaws.com/groups/global/Auth...  READ
  • before:
MYUSERNAME                FULL_CONTROL
Everyone                  READ

Does not seem to affect functionality, but is it intentional?

metadata now has additional __complete__, __service__, __user__ fields - again: intentional?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 1, 2013

@dkocher commented

Replying to [7422 blacktrash]:

metadata now has additional __complete__, __service__, __user__ fields - again: intentional?

This is a bug.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 1, 2013

@dkocher commented

Replying to [comment:2 dkocher]:

Replying to [7422 blacktrash]:

metadata now has additional __complete__, __service__, __user__ fields - again: intentional?

This is a bug.

Fixed in 97841e5.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 1, 2013

@dkocher commented

Replying to [comment:3 dkocher]:

Replying to [comment:2 dkocher]:

Replying to [7422 blacktrash]:

metadata now has additional __complete__, __service__, __user__ fields - again: intentional?

This is a bug.

Fixed in 97841e5.

In dd9cd9b.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 2, 2013

@dkocher commented

Do you know if FULL_CONTROL for the owner of the bucket or file is implicitly given?

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 2, 2013

@dkocher commented

Changes in 56d8784.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 2, 2013

a304470 commented

Replying to [comment:6 dkocher]:

Do you know if FULL_CONTROL for the owner of the bucket or file is implicitly given?

It seems so. At least I can still control the files, even though the permissions in the console now also say:

Grantee: Authenticated Users - x Open/Download
Grantee: Everyone -            x Open/Download

which seems like a useless duplication.

Previously:

Grantee: USERNAME - x Open/Download - x View Permissions - x Edit Permissions
Grantee: Everyone - x Open/Download

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 10, 2013

@dkocher commented

In 4.4 when uploading without Preferences → Uploads → Permissions → Uploads → Change Permissions selected, the uploaded objects have only set

Username Grantee - FULL_CONTROL

See also #7356.

When Preferences → Uploads → Permissions → Uploads → Change Permissions is selected, the ACL set (assuming the file is world readable on the local filesystem or Others → Read is selected for custom upload permissions) is

Everyone - READ
http://acs.amazonaws.com/groups/global/AuthenticatedUsers - READ
Username Grantee - FULL_CONTROL

The http://acs.amazonaws.com/groups/global/AuthenticatedUsers grantee is added when theGoup → Read|Write is selected.

Fix with added canonical grantee with FULL_CONTROL for owner in 1a8c1ce.

Loading

@cyberduck cyberduck closed this Sep 10, 2013
@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants