“Stop sharing this folder” is not the same as “Never share this folder”
A security vulnerability report arrive that went roughly like this:
- Create two users on the system, call them A and B.
- Sign on as A.
- Create a folder, let’s call it X.
- In Explorer, right-click the folder X, and select “Give access to”, “Specific people”, and grant access to B.
- Now right-click the folder X again, and select “Give access to”, “Remove access”, “Stop sharing” to remove access and stop sharing.
- Go up a level and right-click on X’s parent folder, and select “Give access to”, “Specific people”, and grant access to B.
- Sign on as B.
- Observe that B has access to folder X even though access was removed in step 5.
While it’s true that access was removed in step 5, it’s also the case that access was re-granted in step 6.
The finder argued that B should not have access to folder X because B was restricted from having access to the folder by step 5.
Removing access is not the same as “block future access”. Removing access means “Hey, like, if there was anybody that was given access, remove that access entry.” This means that they can’t access this folder directly. However, it doesn’t prevent them from accessing the folder by other means, such as by coming through the parent folder, or (even more simply) by you adding access later.
If you want to deny access to the folder, you can go to Advanced security and add them to the Deny list for the folder.¹
Mind you, even that is not an absolute “block future access”: You could always come back later and remove them from the Deny list.
¹ When you share the parent folder, you are reminded that the subfolder has conflicting security and asks if you want to replace the current security settings on the subfolder with the settings of the parent, or whether you want to keep the separate settings for the subfolder.
Light
Dark
3 comments
On a fileserver, whenever a folder is shared, hit “disable inheritance” on the NTFS rights. For any folder below which has different access rights do the same: No inherited rights are supposed to be left.
On larger environments having several levels of mixed inherited rights is a nightmare to manage, and if a right changes on a parent folder it can take days, literally, until all subfolders with mixed inheritance are updated. Mixed inherited and non-inherited rights can lead to weird effects on access where it gets time costly to trace it down instead of doing it right in first place.
As for “deny” access: I avoid it as much as possible. Create an extra write-group (+ extra read-group if needed), following RBAC/ABGL logic, is much better. The ONLY deny right I set on such a “separate ACL” folder is “deny delete” on “everyone”. It not only catches accidental deletion, it catches accidental moving that folder to wherever an acting-up touchpad thinks it should be.
I’m surprised that there exists someone that can’t understand the difference. And I’m not even a system administrator. Just a C++ programmer.
Last week we had auto-generated content farming for Windows kernel stop codes. This week we have Windows vulnerability reports written by AI. The reporter has no more understanding of file systems than any of the AI models, and yet they churned out a plausible-on-the-surface security bug report.