Etag does not change when access to a reshared file is lost due to permissions removal

[davivel]

Steps to reproduce

1. As user1, share a folder '/shared/' with user2 (with all permissions)
2. As user2, reshare '/shared/' with user3 (with all permissions)
3. As user3, login to see '/shared/' in root; check Etag of root folder for user3
4. As user1, remove 'can share' permission on folder '/shared/' for user2
5. As user3, login to shee '/shared/' disappeared from root; check Etag of root folder for user3

Expected behaviour

Etag of root folder in points 3 and 5 should be different, since the contents of root folder changed.

Actual behaviour

Etag of root folder in points 3 and 5 is the same; this results in clients not syncing / refreshing the removal of '/shared/' in user3 account; tested in Android, requires a forced refresh of root folder (ignores Etag) to correcly refresh root.

Server configuration

Operating system:
Ubuntu

Web server:
Apache

Database:
MySQL

PHP version:

ownCloud version:
8.2.2 (stable)

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results here.

File not found

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption:
No

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
No

Client configuration

OC for Android 1.9.1 (in progress)

[davivel]

Related to #9304 ?

[davivel]

cc @rullzer @PVince81

[PVince81]

@davivel possibly related, yeah

CC @icewind1991 for etag propagation

[PVince81]

also @icewind1991 is already currently looking into making shares disappear from the user's view whenever sharing was disabled through any means, for 9.0. So with a bit of luck it might cover this case as wel.

[davivel]

Cool. Not a blocker for us, but nice to have.

[icewind1991]

Afaik this is already fixed in 9.0

[davivel]

@icewind1991 , no, I tested with master and the etag doesn't change. Moreover, in the step 5 the folder is still accessible by user3. ¿¿¿¿????

Should I test with a different branch?

[rullzer]

@davivel how did you create the shares? Using the OCS endpoint or via the webUI?

[davivel]

In my original test, when opened the issue, I used OCS endpoints from the OC app for Android.

In the last test with master branch I used the web UI for steps 1 to 3, and OCS for the steps 4 & 5; sorry, I didn't think it could make a difference :S

[rullzer]

@davivel well there won't be again shortly. But right now the OCS endpoint uses the new resharing behaviour while the webUI still creates shares the old way.

Please recheck once #21860 is in.

[davivel]

So I'll do.

[rullzer]

@davivel it is in...please retest to see if the issue persists

[davivel]

Thanks @rullzer , will check today.

[davivel]

Well, now this is not working as we expected, but I guess this time is due to the new semantics of resharing.

As I see in the web UI, after the steps in 1-4 in the description, user3 still receives '/shared/' as a shared folder. This is different than behaviour in 8.2.2, where the folder was not reshared anymore after the step 4.

On the other hand, user1 is watching in the web UI two shares: that directly created by it in step1 with user2, and that created by user2 with user3. This is different than 'til 8.x, where user1 only would see the share it created directly.

AFAIK this is new and intended. Am I right?

So, I guess that in the web UI, the request to show the list of shares for the folder now is using also the parameter reshares=true. Otherwise the API doesn't list the second share created by user2. Is it this way?

@rullzer

[rullzer]

@davivel yes you are correct. In the new sharing behaviour the owner always has to complete overview of the shares.

[rullzer]

@davivel but the etag of the root gets updated correctly now on permission modification now right?

If so please close :)

[davivel]

True, the ETag is updated as requested, so this is fixed.

Anyway, be warned that probably I'll be back to know more about the new semantics on resharing ;)

Thanks!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.