Skip to content

Conversation

@nickvergessen
Copy link
Member

Signed-off-by: Joas Schilling [email protected]

Copy link
Member

@rullzer rullzer left a comment

Choose a reason for hiding this comment

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

🙈

@ChristophWurst ChristophWurst added 4. to release Ready to be released and/or waiting for tests to finish bug labels Nov 27, 2019
@rullzer rullzer added 2. developing Work in progress and removed 4. to release Ready to be released and/or waiting for tests to finish labels Nov 27, 2019
@rullzer
Copy link
Member

rullzer commented Nov 27, 2019

tests do boom

@nickvergessen nickvergessen force-pushed the bugfix/noid/prevent-creating-users-with-existing-files branch from 7f919be to 6004f62 Compare December 4, 2019 14:22
@nickvergessen
Copy link
Member Author

I fixed our "unit" tests.... arg

@nickvergessen nickvergessen added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Dec 4, 2019
@nickvergessen nickvergessen requested a review from rullzer December 4, 2019 14:23
@rullzer rullzer merged commit 04c2b5f into master Dec 5, 2019
@rullzer rullzer deleted the bugfix/noid/prevent-creating-users-with-existing-files branch December 5, 2019 09:30
@thomas-mc-work
Copy link

This change prevented us from a migration of files: We have provided only the files from an old Nextcloud instance into the data directory of a new one. With Nextcloud 17 this scenario was fine. The user could log in and see his files. Now they get an error 403 without any further info. I couldn't even find something about that in the log file.

  1. A meaningful log entry would be very useful to avoid hours of research for other admins in that situation
  2. Why has that been changed at all? This PR isn't linked to an issue.

@nickvergessen
Copy link
Member Author

The link was missing, it is #16196
and is a follow up to #14652 which is the result of a reported security issue: https://nextcloud.com/security/advisory/?id=NC-SA-2019-015

@thomas-mc-work
Copy link

thomas-mc-work commented Mar 26, 2020

Thank you for your quick reply @nickvergessen!

Actually my on only problem is about line 642:

return !file_exists(rtrim($dataDirectory, '/') . '/' . $uid);

This was only return true; in the first PR. Also this isn't addressed by the mentioned security advisory. So my questions are only focused on that line.

@nickvergessen
Copy link
Member Author

Well before it was hardcoded to what we know. But if an app creates something in root, it could still be overwritten by creating a user.

I don't know how you create your users, but what you can do is:

  1. Create the user
  2. Move their files in place
  3. Run ./occ files:scan <user id> to make the files appear for the user

@thomas-mc-work
Copy link

thomas-mc-work commented Mar 26, 2020

Yes, that's possible. But we've got about 700 Users. And they are provided by an external auth module (user_cas), so Nextcloud isn't aware of them before they log in the first time. Maybe it would have been good to clean the data dir by moving the user accounts into a separate sub folder named users.

But if an app creates something in root, it could still be overwritten by creating a user.

Has this really been an issue to someone? Are apps even encouraged to write into this folder?

@nickvergessen
Copy link
Member Author

Has this really been an issue to someone?

Well it's a security thread so we fix it.

Are apps even encouraged to write into this folder?

Not encouraged, but we also don't prevent it

We will not revert this, in case you accept this security risk you can change your code. But don't come back here when your nextcloud got hacked because of it 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3. to review Waiting for reviews bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants