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

Setupfs before access a users keys #26917

Merged
merged 5 commits into from
Jan 13, 2017
Merged

Conversation

PVince81
Copy link
Contributor

Forward port of #26824 to master.

I've retested with the md5 home hack and it works fine.

Automated test will appear when #26844 gets merged.
We should first merge this encryption fix before we can merge the tests PR to avoid failures.

Please review @DeepDiver1975 @jvillafanez @SergioBertolinSG

@PVince81 PVince81 added this to the 10.0 milestone Jan 11, 2017
@mention-bot
Copy link

@PVince81, thanks for your PR! By analyzing the history of the files in this pull request, we identified @DeepDiver1975 to be a potential reviewer.

@PVince81
Copy link
Contributor Author

Repasting the steps here because it's a long way to find them:

Steps

  1. Setup LDAP with special home folder rule, where home folder name is different than the user id
  2. Enable encryption
  3. Login as a LDAP user zombie2 (to initialize encryption keys)
  4. Login as a LDAP user zombie1
  5. Create a folder "test"
  6. Upload a file "bacon.txt" into "test"
  7. Share "test" with "zombie2"
  8. Login as "zombie2"
  9. Open/download file "test/bacon.txt"

Before this fix: public key exception
After this fix: file can be read

@@ -64,6 +67,11 @@ public function __construct(View $view, Util $util) {
$this->encryption_base_dir = '/files_encryption';
$this->keys_base_dir = $this->encryption_base_dir .'/keys';
$this->root_dir = $this->util->getKeyStorageRoot();

$session = \OC::$server->getUserSession();
Copy link
Member

Choose a reason for hiding this comment

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

I guess it would be a pain to inject this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, apparently not. This class is only in one place in server.php, so I'll add it.

*
* @param string $uid user id
*/
protected function setupUserMounts($uid) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe this function should return something to check the result of the initMountPoint (if any) or to check if the function is ignoring the request because the uid matches the current user or the mount point is already mounted, specially if there are plans to unittest this function.

Since it isn't public we might skip testing this.

@@ -55,6 +67,8 @@ public function setUp() {
->disableOriginalConstructor()
->getMock();

$this->createUser('user1', '123456');
Copy link
Member

Choose a reason for hiding this comment

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

I think this will create a user each time a test runs, which seems wrong.

Either you create the users in the setUpBeforeClass method (and maybe delete them in the tearDownAfterClass method) or you delete them in the tearDown method so the next tests recreate them without any problem

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, I forgot to re-delete the user. Will do.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I checked the code. Apparently createUser comes from UserTrait which itself uses the Dummy user backend which is reset after every test. So no need for additional changes here.

@SergioBertolinSG
Copy link
Contributor

Works using detailed steps from #26917 (comment)
👍

Used displayName as special home folder rule.

@PVince81
Copy link
Contributor Author

Setting back to "Developing". I'll address @jvillafanez's relevant comments.

@PVince81 PVince81 self-assigned this Jan 12, 2017
@PVince81
Copy link
Contributor Author

@jvillafanez adjusted, please recheck.

I only indirectly tested the setupUserMounts, I had to do a big detour to find out whether the mounts are setup without triggering the setup through the check. (MountManager->getAll does that)

@jvillafanez
Copy link
Member

👍

@PVince81
Copy link
Contributor Author

PVince81 commented Jan 13, 2017

  • TODO: backport the additional unit test to the other branches (yay, snakeport!)

@PVince81 PVince81 merged commit a4883ae into master Jan 13, 2017
@PVince81 PVince81 deleted the setupfs-before-access-a-users-keys branch January 13, 2017 08:51
@PVince81
Copy link
Contributor Author

First regression already... #26935

@PVince81
Copy link
Contributor Author

First missing piece to properly deal with "alternative keys storage root" in which case we don't need to mount anything, see #26937

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

5 participants