We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
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 emp...
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
Dropbox Staff
Dropbox StaffThanks 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.
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.
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.
