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

Prefilter inaccessible shares in DefaultShareProvider::getSharedWith() #26016

Merged
merged 1 commit into from
Sep 7, 2016

Conversation

PVince81
Copy link
Contributor

@PVince81 PVince81 commented Sep 2, 2016

Description

See #26001 for context.
We need to prevent the shared mount provider to expose mounts where the source file is not accessible any more when in trash or completely deleted. This is important to avoid issues where the user cannot create a folder with the name of the mount point because it's still there but "ghosted".
This fix guarantees that the mount point is not present at all and all code paths for file operations won't be impaired by a ghost mount.

What this does: prefilter inaccessible shares in DefaultShareProvider::getSharedWith()

The DefaultShareProvider now does a DB-level check to find out whether file_source is accessible at all (deleted file) or whether it's in the trashbin of a home storage.

Note: One small corner case where the home storage id is in md5 form cannot be covered properly with this approach. This would only happen for user ids longer than 64 - strlen('home::') which is 58 characters. LDAP ids are usually shorter than that.

Related Issue

Fixes #26001

Motivation and Context

Pfff, because of shared storage HELL, that is. See context.

How Has This Been Tested?

  • TEST: shared folder still received when not deleted
  • TEST: fileid pointing to non-existing file
  • TEST: fileid pointing at file in trash
  • TEST: create folder "sub" then restore the file as owner
  • TEST: rename another folder to "sub" when invisible/ghosted
  • TEST: "Shared with you" section in files app still shows existing valid entries

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

Backports:

  • stable9.1

Open TODOS:

  • write unit test

@PVince81 PVince81 added this to the 9.2 milestone Sep 2, 2016
@mention-bot
Copy link

@PVince81, thanks for your PR! By analyzing the annotation information on this pull request, we identified @rullzer, @DeepDiver1975 and @nickvergessen to be potential reviewers

@PVince81
Copy link
Contributor Author

PVince81 commented Sep 2, 2016

Please review, I'd like to know whether this approach is acceptable before I dive into the pain of writing tests. Thanks.

->selectAlias('st.id', 'storage_string_id')
->from('share', 's')
->leftJoin('s', 'filecache', 'f', 's.file_source = f.fileid')
->leftJoin('f', 'storages', 'st', 'f.storage = st.numeric_id');
Copy link
Contributor Author

Choose a reason for hiding this comment

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

ping DB experts @butonic @DeepDiver1975

I hope this is acceptable... Will this kill Oracle ?

Else I can make subqueries for this, not sure about perf...

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, use $qb->expr()->eq()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Assuming "Yes" is the answer for the first question "I hope this is acceptable". Thanks.

I'll change it to use $qb->expr()->eq()

Copy link
Contributor

Choose a reason for hiding this comment

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

The yes was to "Will this kill Oracle ?"

@PVince81 PVince81 force-pushed the prefilter-inaccessible-shares branch from 97efbd9 to afa6a99 Compare September 3, 2016 15:33
@PVince81
Copy link
Contributor Author

PVince81 commented Sep 6, 2016

Test failures unrelated.

Please review @butonic @jvillafanez @DeepDiver1975 @VicDeo, needed for 9.1.1

}

// exclude shares leading to trashbin on home storages
$pathSections = explode('/', $data['path'], 2);
Copy link
Member

Choose a reason for hiding this comment

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

What about external storages? Will they work properly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, see below, the crude check for home storage

@jvillafanez
Copy link
Member

👍

@PVince81 PVince81 force-pushed the prefilter-inaccessible-shares branch from afa6a99 to 472dbc7 Compare September 6, 2016 13:40
@PVince81
Copy link
Contributor Author

PVince81 commented Sep 6, 2016

Rebased for hopefully passing tests

@PVince81 PVince81 mentioned this pull request Sep 6, 2016
15 tasks
The DefaultShareProvider now does a DB-level check to find out whether
file_source is accessible at all (deleted file) or whether it's in the
trashbin of a home storage.

One small corner case where the home storage id is in md5 form cannot
be covered properly with this approach.
@PVince81
Copy link
Contributor Author

PVince81 commented Sep 7, 2016

stable9.1: #26050

(yes, am optimistic about the tests...)

@lock
Copy link

lock bot commented Aug 4, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lazy shared storage heII: ghost mounts
4 participants