Allign WebDAV's <oc:permissions> with ocs permissions on PROPFIND

[ckamm]

With 8.2.0:

• Have two accounts A, B
• Share a file <A>/file to <B>/file with all permissions
• Look at the permissions returned for /file in PROPFIND of <B>/ and <B>/file. Both should be SRDNVW.
• Remove the edit permissions from the share.
• Look at the permissions again. The PROPFIND for <B>/file returns SRDNV (correct), but the <B>/file entry in the directory propfind continues to say SRDNVW.

This has the practical implication that the desktop sync client will not have up to date information about the file permissions and will behave incorrectly. owncloud/client#3244

@DeepDiver1975 @PVince81

[rullzer]

Ah permission mess :)
The trouble is that we here try to map two different permission sets in 1 field. On the one hand we have the share permissions and on the other hand we have the oc filesystem permissions.

If you propfind on the root it will see hey there is a mountpoint /file. And it will retrieve the permissions correctly. However because it is a mountpoint in / it will say. Well it is a share so the receiver can always rename (move mountpoint) or delete the file (unshare).

Now if you do a propfind directly on /file it won't do all this mountpoint magic (since you profind just a file). And thus return the correct permissions.

So actually this is 2 bugs.

1. Different permissions
2. No way to get the proper share permissions

[PVince81]

From my understanding the sync client only needs the permissions to find out whether or not to attempt a server call. If the permissions are too permissive, it isn't that bad if the sync client needs to make a server call to see it fail afterwards. So it's just a way to save server calls. Correct me if I'm wrong @ckamm 😄

With that assumption, we could make it so that the "PROPFIND /file" returns the same permissions as the sub-result from "PROPFIND /".

[rullzer]

@PVince81 not exactly. The clients wants to mark files that it can't edit as read only. So the uers will get notified on their system that they can't save the file. Right now they can edit the file just fine. Save it. And then the client will tell them there is a problem when uploading.

[PVince81]

@icewind1991 can you comment on this ? Was this behavior originally on purpose ?

[PVince81]

This also means that when we make the web UI use Webdav we might encounter similar issues.

[PVince81]

Looks like this behavior exists since OC 7 already.

[PVince81]

I see some perms manipulation here in getDirectoryContents(): https://github.com/owncloud/core/blob/v8.2.0/lib/private/files/view.php#L1362
That's used by PROPFIND with Depth: 1.

[rullzer]

I see some perms manipulation here in getDirectoryContents(): https://github.com/owncloud/core/blob/master/lib/private/files/view.php#L1370
That's used by PROPFIND with Depth: 1.

YES!. When I ran with XDebug yesterday that was the point. Permissions are fine till that point.
We add those there because it is a mount point (moveable mount point). So we can always move and delete it.