Skip to content

Transfer ownership must work with master key #27427

Closed

Description

@PVince81

Transfer ownership should be possible because it doesn't require any user's specific password.

Currently it doesn't:

Steps:

  1. cd tests/integration
  2. Edit transfer-ownership.feature and remove "no_encryption" tags
  3. sudo -u wwwrun OC_TEST_ENCRYPTION_MASTER_KEY_ENABLED=1 ./run.sh features/transfer-ownership.feature

Expected:

All tests passing.

Actual:

Transfer ownership refuses to work because it detects encryption.

  • adjust isReadyForUser to return true if master key is used
  • somehow detect that encrypted files are ok when master key is enabled instead of asking for decryption. This is a bit tricky because it requires calling non-specific encryption manager APIs.

Maybe add a method to the encryption modules to let them tell whether moving files between users can be done without their passwords ?

@pmaier1 will become more important when we start fading out the default encryption

Activity

  1. added this to the backlog milestone on Mar 20, 2017
  2. modified the milestones: 10.0.2, backlog on May 8, 2017
  3. modified the milestones: 10.0.3, 10.0.2 on May 26, 2017
  4. added
    p2-highEscalation, on top of current planning, release blocker
    on May 26, 2017
  5. PVince81 commented on May 31, 2017

    @PVince81
    ContributorAuthor

    @sharidas please take care of this, thanks

  6. sharidas commented on May 31, 2017

    @sharidas
    Contributor

    Sure

  7. butonic commented on Jun 6, 2017

    @butonic
    Contributor

    @pmaier1 @PVince81 we fade out the individual user key based encryption?

  8. PVince81 commented on Aug 7, 2017

    @PVince81
    ContributorAuthor

    While the merged PRs seem to work, there is a risk that it will not always work correctly in case the storage wrappers are setup differently. The problem is here: https://github.com/owncloud/core/pull/28107/files#diff-938b56891f3079e628cfda1c331911b7R366

    This adds an argument to fopen which at first look seemed fine but in hindsight I remembered that if the encryption wrapper is itself wrapped by another fopen wrapper, the latter will likely not forward the value to the encryption wrapper, so it would break.

    So far we are lucky that it works fine for transfer ownership but could break with third party apps.

    I'm moving this ticket to "planned" now to look into other ways to pass around that value. This is quite tricky with the current architecture without resorting to globals...

  9. modified the milestones: , development on Aug 7, 2017
  10. PVince81 commented on Sep 14, 2017

    @PVince81
    ContributorAuthor

    @sharidas please link to the PRs where you cleant up the tech debt mentioned above, then close.

  11. sharidas commented on Sep 14, 2017

    @sharidas
    Contributor

    The PR which addresses issue referred #27427 (comment) is here #28774 . This is another PR which got addressed #28820 and merged.

  12. lock commented on Aug 1, 2019

    @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.

  13. locked as resolved and limited conversation to collaborators on Aug 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions