Child Item

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

Dropbox Business Standard with multiple users. Folders that are not shared with a user still show as an empty folder for that user. They can access the folder but not the files - it looks like an empty folder. Linux (Ubuntu 22.04) users can simply delete that empty folder, which results in Dropbox removing it and its contents from all other users. That seems like a serious issue. Windows users get a message and Dropbox refuses to delete, but that's not the case in Ubuntu, it has to be recovered from Deleted Files - again.

Find more posts tagged with

Delete

Dislike

Comments

Walter

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!

asnell

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

Walter

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.

asnell

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

Demitri

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.

asnell

@Здравко, 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.

asnell

Hello @Здравко . That is better in some ways and I'll actually leave it set to "Only admins". You can see the top level Dropbox directory is now readonly.

However, this means even I can't create a top-level folder, even though I am admin. I can't even create one in the browser interface, the option is disabled!

It's OK, I can set it to "Everyone", create top-level folders and then set it back to "Only admins". It will be rare that I need to do that.

When set as "Only admins" and a user adds write access to the directory they can still delete an unshared folder but it only deletes it locally and it reappears at the next sync. So set at "Only admins" is much safer, if a little inconvenient.

Still not nice that an empty directory is shown but I can live with that.

Thank you for your help.

asnell

@Здравко - I see, I can create folders in the Admin section.

Thanks again.

Здравко

@asnell wrote:
...
However, this means even I can't create a top-level folder, even though I am admin. I can't even create one in the browser interface, the option is disabled!
...

Not exactly... When you logged in your application you become there just a team member (part of "Everyone" set), no more admin. That's why you cannot create such folder there - like "Everybody". 😉 As you found out, admin section does this.

Good luck.