Linux users can delete folders (including content) that are not shared with them

Hey asnell, thanks for bringing this to our attention.

Can you please clarify if those are team folders, shared folders or personal folders perhaps? 

Are all members of the team noticing this or a specific one or a team admin? 

If you could also share some screenshots so that we can have a visual too, I'd appreciate it. 

Thanks!

Hi Walter,

This happens with shared folders, created as shown in first image.

The following images show two Linux computers. The one on the left is the user with shared access, the one on the right does not have shared access. These show command line but the same happens when deleting the folder using a file manager. The folder, which appears empty, can be deleted by the user without shared access.

The shared folder "notforall" has a file "testfile" in it.

This happens with multiple Linux machines I have here running Ubuntu 22.04 and Linux Mint 21. It happens the same with different users. It does not happen with Windows computers running the same users, they get access denied.

Thank you.

Andrew

Thanks for the additional information and the screenshots too asnell - much appreciated.

It sounds like you may have set your top level folders to be editable by all team members - could it be that what's causing this? 

If you choose Everyone, you can either use the Content page, the All files page, or the desktop app to manage the top level of the team space as outlined here. 

Thank you, I'll have a read through that shortly as it may help.

I have investigated more and in all Linux distros I have checked, an empty directory can be deleted even if the user doesn't have write access. So DropBox is showing the folder but, because the user doesn't have access to the content it is empty. The write attribute is cleared so in theory a user can't do anything with it, and that works in Windows. In Linux a user can delete such an empty directory, even without write access. This deletion then gets synchronised by the Dropbox desktop client and removed from other users who do (or did) have shared access.

I have been on to Dropbox support about it and they have passed it on to somebody else. I can work round the problem now I know about it and what is causing it.

Thanks again for your attention.

---

Walter wrote:

...

It sounds like you may have set your top level folders to be editable by all team members - could it be that what's causing this? 

...

---

It's just not true, Walter. As can be seen both from folder setup (web view) and from console output, the folder is correctly setup as writable for first user and read-only for second one. 🙂 Classical application BUG and not only. Not only because with inappropriate credentials, this should NOT be possible on the Dropbox server despite possible locally, but it happens (as can be seen). Just as a hint to your application development staff - setting read only to particular folder doesn't restrict this folder to be deleted, it only restricts changes to the folder content (there is nothing right now, because restriction set to the user 😁) - for reference: POSIX.

---

asnell wrote:

... The write attribute is cleared so in theory a user can't do anything with it, and that works in Windows. ...

---

Hi asnell,

Not exactly! User cannot change content only. This is the same both for files and for folders. It's another story how much Windows matches to any standards.

---

asnell wrote:

... In Linux a user can delete such an empty directory, even without write access. ...

---

Yes, and that's correct behavior. Permission to change/delete a folder (not its content) are described by access that's set to the containing folder. The target folder is a content of its parent folder.

---

asnell wrote:

... This deletion then gets synchronised by the Dropbox desktop client and removed from other users who do (or did) have shared access.

...

---

And this is a real security issue!!! That means user can make some changes even when appropriate permission is missing! Bad thing...

Heya; I'm Demitri -- I'm on our escalations team.

Sorry to hear you ran into issues there. 

What you've described is currently an expected behavior (though admittedly: we know it has the capacity to lead issues like you've described). The short explanation being: Dropbox allows you to have more dynamic permissions where you can have expanding or restricting permissions as you go down levels in your folder structure.

So if my Dropbox account has a folder path with permissions that looks like: 

-/Share 1/                  [edit access]
- - /Share 2/              [view access]
- - - /Share 3/            [edit access]

I'm able to modify objects inside of "Share 1" - that includes deletion. "Share 2" is an object inside of "Share 1" where I have edit permissions so I have the ability to delete that. I do not have edit access to make changes inside of "Share 2" - and any objects in there could not individually be affected by my account, except contents inside of "Share 3" where my imaginary account also has access. 🙂

This can affect any Dropbox account - but where I see this cause the most problems for people is usually Dropbox Business teams, specifically here: 

https://help.dropbox.com/organize/manage-team-space 

When the option to allow all members of a team to edit the top level of your shared workspace is enabled. Disabling this means only Dropbox team admins will be able to create/remove top level team folders moving forward (though members will still be able to manage access inside of those folders as needed) so accidental moves/deletes like this are less likely. 

So for the moment, this is something to be wary of. If this is particularly impactful to your team's organizational setup: I'm happy to collect feedback from you all about how you use sharing/file organization within Dropbox, and any feedback you'd like to bring to our product development team about this functionality. 

Thanks ya'll!

Demitri, Your explanation of the current state is not very consistent! How is a user that don't have access to particular folder able to delete it? That should be possible only when the folder is empty, but in particular case in Dropbox server it's NOT!!! That makes the case a security issue. You definitely have some more work to do for users files protection.

The problem in particular situation, described by asnell, is that despite the folder is not empty on the server it appears empty locally (which makes deletion possible). In meantime, until waiting for real solution, workaround can be putting some file in such folders, like ".dropbox" and ignored in the same way (might be even empty). In such a way direct folder deletion would be impossible - non empty folder. Another way is wipe out all standard flags (not only the write flag, like now). In such a way direct deletion would be impossible too - the system cannot see whether the folder is empty or not, so assumes there is something (as is actually on the server). 😉

Hope this helps some issues fixing to some extent.

Здравко, you have understood the problem correctly. It was a little hard to explain.

The whole problem starts with the folder being shown to a user who does not have access to the contents and ends with the fact that the empty directory can be deleted on a Linux machine. The folder and all contents then get deleted for all the users who did have access.

asnell, when you login to dropbox.com with admin credentials and go to admin console, under settings there, what can be seen as content management? Is it set to "Everyone" or "Only admins"?

Make sure it's set to "Only admins"! Does this change something (to some extent at least)? 🧐

Add: After that, list the content in your Dropbox folder using:

ls -al

To be seen the dot folder' flags.