Skip to content

Conversation

@susnux
Copy link
Contributor

@susnux susnux commented Nov 17, 2023

Summary

Drop file permissions on copy like we do on local storage.

Checklist

@susnux susnux added this to the Nextcloud 28 milestone Nov 17, 2023
@susnux susnux requested review from a team, Altahrim, icewind1991 and sorbaugh and removed request for a team November 17, 2023 07:45
@susnux susnux requested a review from juliusknorr November 17, 2023 10:24
@susnux
Copy link
Contributor Author

susnux commented Nov 17, 2023

/backport to stable27

Drop file permissions on copy like we do on local storage.

Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
@susnux susnux force-pushed the fix/object-storage-inconsitent-behavior branch from 6c30781 to 5172baa Compare November 17, 2023 11:54
Copy link
Member

@juliusknorr juliusknorr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small comment, but looks good otherwise

if (isset($params['validateWrites'])) {
$this->validateWrites = (bool)$params['validateWrites'];
}
$this->handleCopiesAsOwned = (bool)($params['handleCopiesAsOwned'] ?? false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a parameter for that actually? If we keep it it should be documented

Copy link
Member

@joshtrichards joshtrichards left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From your inline comments it seems you think the local (non-object) policy is the broken one. I'm not sure local's behavior is incorrect (seems object is), but I appreciate the conservativeness to add a config option to avoid changing existing behavior for object (in case someone is relying on it).

But I think it should just outright be made consistent with local as-is w/o config option if at all possible. There's just no justification for having different behavior (or a switch for one but not the other/etc)

Do we have any idea when this inconsistent behavior was introduced or has it seemingly "always" been this way?

@blizzz blizzz mentioned this pull request Nov 20, 2023
5 tasks
@susnux susnux merged commit 9c3321c into master Nov 22, 2023
@susnux susnux deleted the fix/object-storage-inconsitent-behavior branch November 22, 2023 12:54
@AndyScherzinger
Copy link
Member

Do we have any idea when this inconsistent behavior was introduced or has it seemingly "always" been this way?

@joshtrichards Has always been like this, since native S3 copying respects the original file's permissions. One could argue that it does so for a reason because the permission had been the decision of the original owner of the file. At the same time, like you mentioned you could also argue the other way around that the copy belongs to the copying party and hence all permission-limitations are dropped.

@icewind1991
Copy link
Member

I think the new behavior is wrong, the permissions on object storages are not related to the permissions of the objects in the objectstore, but only the permissions from things like sharing/acls.

See #53733 for making the local storage behave as the object store used to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

[Bug]: Inconsistent copy behavior between Object storage and local storage

8 participants