core icon indicating copy to clipboard operation
core copied to clipboard

User deletion does not remove shares

Open cortho opened this issue 2 years ago • 3 comments

Steps to reproduce

  1. As admin create an "empty folder" and share with user intermediate
  2. As user intermediate re-share this folder to user test
  3. As user test you will see the shared "empty folder"
  4. As admin delete user intermediate
  5. As user test the directory "empty folder" still exists.
  6. In the share tab there is still visible that the folder was shared by intermediate

Expected behaviour

Shares by deleted users are deleted when a user is deleted, since there it says:

You are about to delete a user. This action can't be undone and is permanent. All user data, files and shares will be deleted. Are you sure that you want to permanently delete intermediate?

Actual behaviour

Shares by deleted users still exist.

This leads to unpredictable consequences since affected shares cannot be removed any longer and there's no chance to change share permissions of such broken shares.

Additionally an occ:maintenance repair does not remove that broken share either.

Server configuration

Operating system: Ubuntu 20.04.4

Web server: apache 2.4.41

Database: mariadb 10.3.34

PHP version: php 7.4.29

ownCloud version: (see ownCloud admin page) 10.9.1.2

Updated from an older ownCloud or fresh install: fresh install

Where did you install ownCloud from: ownCloud download page

Signing status (ownCloud 9.0 and above): fine

The content of config/config.php: default setup after initial installation

List of activated apps: only apps installed by default

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

Are you using encryption: yes/no no

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

Client configuration

irrelevant

ownCloud log (data/owncloud.log)

no related log entries

Browser log

no related log entries

cortho avatar May 11 '22 11:05 cortho

The reshare of a resource "owned" by admin from intermediate to test "becomes" a share from admin to test with data to show that it was created by the action of intermediate.

I tried this, and after deleting intermediate, I can login as admin and see the share to test. As admin, I can delete the share without any problem.

When a user grants "reshare" permissions on a share, they are effectively delegating the ability to share the resource on their behalf - in this example, admin has delegated that ability to intermediate. But when intermediate does the reshare, the share is effectively admin's share.

Maybe the UI (and somewhere in API requests) needs to show more clearly that intermediate user no longer exists?

phil-davis avatar May 11 '22 11:05 phil-davis

So then the issue is, that uid_initiator is not updated in oc_share on user deletion. This makes it impossible

  • to find out for sharees who is "responsible" for the share (i.e. who can change permissions)
  • to see which files are actually shared by admin since it wouldn't show up in "Shared with others" view.

Edit:

  • The information in the user deletion alert is ~wrong~ not so correct, when shares are not deleted

cortho avatar May 11 '22 11:05 cortho

to see which files are actually shared by admin since it wouldn't show up in "Shared with others" view.

true, in the web UI, when I go to "Shared with others", there is nothing shown.

But when I go to "All Files", the folder shows "Shared" and when I open the sharing sidebar, I can see that it is shared with "test".

The "Shared with Others" UI view, and related API responses, need to be smarter about showing all resources "owned" by the user (in this example, admin) that are accessible to others. In this particular case, finding reshares even though the resharer no longer exists.

phil-davis avatar May 11 '22 11:05 phil-davis