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

Add isDeletable() check to OC\Files\Node::move() #27734

Conversation

PhrozenByte
Copy link
Contributor

Moving a file (or directory) is the same as creating a copy of the file and deleting the original one. This is also enforced on a filesystem level: One can't move 'foo/test' to 'bar/test' unless the user has 'wx' permissions on both 'foo' and 'bar'. In practice this never was an issue because the low-level storage returns 'false' anyway, but it might be in the future.

Moving a file (or directory) is the same as creating a copy of the file and deleting the original one. This is also enforced on a filesystem level: One can't move 'foo/test' to 'bar/test' unless the user has 'wx' permissions on both 'foo' and 'bar'. In practice this never was an issue because the low-level storage returns 'false' anyway, but it might be in the future.

Signed-off-by: Daniel Rudolf <github.com@daniel-rudolf.de>
Signed-off-by: Daniel Rudolf <github.com@daniel-rudolf.de>
@szaimen szaimen added this to the Nextcloud 23 milestone Jun 30, 2021
@ChristophWurst
Copy link
Member

Moving a file (or directory) is the same as creating a copy of the file and deleting the original one

Is this really the case for all storage? What about object storage and similar?

@PhrozenByte
Copy link
Contributor Author

Since there's no distinct MOVE permission in Nextcloud, but CREATE and DELETE permissions only, this is true for all storages (including object storages), yes. Otherwise we wouldn't check whether we can actually (re)move the original file/folder - the main difference between copy() and move(). Any storage should yield a low-level failure right now, if they don't this is a bug (if not a security issue).

@PhrozenByte
Copy link
Contributor Author

@ChristophWurst Any thoughts?

Copy link
Member

@icewind1991 icewind1991 left a comment

Choose a reason for hiding this comment

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

Nextcloud itself only requires update permissions for moving files within a storage (for example, you can rename files within a share even if you don't have delete permissions).

I think that adding an isUpdateable check for the parent folder handles things correctly.

@PhrozenByte
Copy link
Contributor Author

I think that adding an isUpdateable check for the parent folder handles things correctly.

From a storage's point of view (and the filesystem's) this is basically the same, so I'm fine with it:

public function isDeletable($path) {
if ($path === '' || $path === '/') {
return $this->isUpdatable($path);
}
$parent = dirname($path);
return $this->isUpdatable($parent) && $this->isUpdatable($path);
}

However, this isn't going to work this easily, because the root folder isn't updateable per se. That's probably the reason why there's a separate creatable permission? Anyway, we could add an exception for the root folder, but I'm not sure whether this is feasible... Ideas?

@skjnldsv skjnldsv mentioned this pull request Oct 13, 2021
@PhrozenByte
Copy link
Contributor Author

I'd say that we have a per-design issue here that would require overhauling the file permissions system as a whole, what probably isn't worth it. Opinions?

@skjnldsv skjnldsv modified the milestones: Nextcloud 23, Nextcloud 24 Oct 22, 2021
@skjnldsv skjnldsv mentioned this pull request Mar 24, 2022
@PhrozenByte
Copy link
Contributor Author

Closing as of #27734 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review Waiting for reviews bug low
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants