Score:3

Server

How to properly secure user's folders?

Gregory MOUSSAT

10/22/23, 10:48 AM

On a file server, a base folder contain user's folders:

This base folder is protected against user's actions (deletion, rename, dump of files, etc), users can only read and traverse it:

To protect each user's root folder, I explicitly deny them the right to delete their own folder:

This imply to add a deny on each folder.
Doing it on the base folder does not work: deny to the group Users to delete sub-folders, for This foler only --> they still can delete their own folder, because inherited permissions (deny to delete) have less precedence than explicit permissions (allow to modify).

With my method, users can still hide their own root folder. This is not a problem, but it show the folder is not 100% protected against actions.

do I use the "canonical" method?
how to prevent the users to hide their own folder? Or whatever other annoying things
any suggestions?

147

2 + 2

windows

permissions

Greg Askew

10/29/23, 7:11 PM

As an FYI, many organizations don't share the base folder. User folders typically have their own share. But that isn't a hard rule, if this works for you that's fine. Usually where this or other folder schemes can go sideways is if the permissions are modified incorrectly and no-one notices for a long period of time.

Sabre

10/31/23, 3:23 PM

We do similar, but use ABE. That way the users only see what is theirs. IN that case we do not get this granular on permissions, as their folder would just be recreated by the system if they were to delete it. And if it had anything in it, they needed back, they would put in an IT ticket and have it restored from backup. UNdelete server is a godsend, veeam covers the rest ;) (Has the added benefit of making users admit they deleted their stuff, because only they could have!)

Score:3

Server

Sabre

10/28/23, 3:34 PM

It appears to be the "This folder" in the applies to....

The deny...

The Specials.

This folder, once owner is returned to administrator (Just quicker in my environment to d on my desktop), can be seen, traversed, added to, modified below, but cannot be hidden or deleted by user QUADWORD.

It is denied delete on the folder explicit, denied reading attributes by not being granted, and the permissions you want are set from that point down.

On the plus side, they can create and delete data from that point down, but cannot hide it there either :-)

Edit (More detail): Allow me to elaborate further... It appears that you would like the parent folder (The users' folders) to be treated differently than all the subfolders thereof. So you have to specify settings for "this folder only" and then have more control form that point down. So you effectively need to be explicit on what you want for that "one folder", then be explicit on what you want for "all child objects of this folder", being different. And you have to make sure that the user has neither permissions to change that, or is by proxy allowed to by being owner or a member of any group that can.". In NTFS a delete always overrides a deny, you can test this by making two identical ACLs one with delete the other with allow, and it matters not what order you put them in they will enumerate deletes first, and ignore allows after. Whether or not that ACL is inherited or not is not relevant. It is a resolved level of access from all ACLs that apply to that object. With one exception, no matter what you set, the "Owner" can retake ownership and change. Otherwise you can create mistakes you cannot fix, as owner you can cosmetically lock even yourself out, but you would have the power to go change that (Useful sometimes) ;)

And remember The "effective access" tab is your friend!

+ 4

Gregory MOUSSAT

10/29/23, 8:52 PM

If I replicate your settings, the users can not create files into their root folder. They can only create sub-folders (inside of which they can create files). It appear that "write [extended] attributes" are both needed to create files, but this also allow for hidding. Tested on Windows 10 and 2016.

Sabre

10/30/23, 5:02 PM

The permissions reflect that. On the "subfolders and files only", you can create those permissions for attributes. Will still prevent manipulation of the parent / root (Cannot hide or delete). The crux of the solution is however to set special permissions direct on the folder for "This folder only" and then set separate permissions for "Subfolders and files only" And since you want two conditions that are mutually exclusive (Some deny some allow) you have to do it in layers. Just tested server 22 and 12R2 which are the only I have immediate access to, both worked as prescribed.

Gregory MOUSSAT

10/30/23, 5:04 PM

"Whether or not that ACL is inherited or not is not relevant" You are wrong. Inherited ACLs are superseded by explicit ones, this is easily tested, and widely documented.

Sabre

10/30/23, 5:20 PM

My assertion was the deny/delete would not care, an explicit deny overrides an inherited allow. We are saying the same thing ;)

Score:1

Server

Bernad MAVISSU

11/2/23, 1:50 PM

1. do I use the "canonical" method?
You use the most straightforward and less error-prone method: the allow item is usual, and the deny item is only one check-mark.

2. how to prevent the users to hide their own folder? Or whatever other annoying things
The fact that users can hide their own folder is related to the fact they also can modify other desirable attributes (but very few do it). I never seen anyone fighting against this, probably because this never cause problems.

3. any suggestions?
Lots of admins prefer to create a share for every "root folder". This can be handy, but this can reveal private informations because shares are visible.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to properly secure user's folders?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.