Fixed an ACL bug which disallowed renaming of files in certain configurations

[x7airworker]

Steps to reproduce the issue

1. Create a groupfolder with advanced permissions enabled
2. Create an ACL configuration which only allows read access to a user/group for the groupfolder.
3. Create a folder inside the groupfolder and give read/write/create permissions to a user/group.
4. Create another file inside this folder will full access.

The file created in step 4 can now be deleted and recreated, but not renamed because the delete permission is missing in the parent folder.
The fix I propose checks the element itself or the parent for the required permission. Please let me know if there is a better way or this is a security risk.

[come-nc]

There is a test by @icewind1991 which seems to expect rename to fail in this case.

@icewind1991 Can you review the test and the PR?

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

[x7airworker]

@icewind1991 Kindly bumping this one :)

[icewind1991]

Nextcloud generally requires write permissions on the parent folder for renames, mirroring the way the permissions work on linux.

Only checking the file could be used to bypass "deny delete" permissions on a folder by moving files outside of the folder before deleting them.

One possible improvement here would be to not require delete permissions (but still require write) on the parent folder if the file is just being renamed, not moved (so target parent and source parent are the same)

[x7airworker]

Well I thought that the rename operation is somewhat equivalent to deleting the file and recreating it.
An improvement is definitely needed, because this basically breaks any (useful) folder creation in folders without delete permissions.
Just out of interest: In my example the file to delete is in a parent folder without delete permissions, but with delete permission on the file itself (basically overwriting it). The deletion works just fine, no need for a "deny delete" bypass.

But I think that your proposed implementation would certainly be better.

[x7airworker]

@icewind1991 Could you take a look at my changes? I've tested it locally and it seems to work without issues.

[icewind1991]

approach looks good 👍

[come-nc]

@x7airworker Some commits are missing the sign-off, can you sign them off or squash them and force push again to fix the DCO ci step?

[x7airworker]

@come-nc Done.