Give access to a subdirectory without giving access to parent directories

Question

I have a scenario involving a Windows file server where the "owner" wants to dole out permissions to a group of users of the following sort:

• \\server\dir1\dir2\dir3: read, write and execute
• \\server\dir1\dir2: no permissions
• \\server\dir1: no permissions
• \\server: read and execute

To my understanding (Update: This entire paragraph is wrong!), it is not possible to do this because Read & Execute permission must be granted to all the parent directories in a directory chain in order for the operating system to be able to "see" the child directories and get to them. Without this permission, you can't even obtain the security context token when trying to access the nested directory, even if you have full access to the subdirectory.

We are looking for ways to get around this, without moving the data from \\server\dir1\dir2\dir3 to \\server\dir4.

One workaround I thought of, but which I am not sure if it will work, is creating some sort of link or junction \\server\dir4 which is a reference to \\server\dir1\dir2\dir3. I am not sure which of the available options (if any) would work for this purpose if the user does not have Read & Execute permission on \\server\dir1\dir2 or \\server\dir1, but as far as I know, the options are these:

• NTFS Symbolic Link,
• Junction,
• Hard Link.

So the questions:

• Are any of these methods suitable to accomplish my goal?
• Are there any other methods of linking or indirectly referencing a directory, which I haven't listed above, which might be suitable?
• Are there any direct solutions that don't involve granting Read & Execute to \\server\dir1 or \\server\dir2 but still allowing access to \\server\dir1\dir2\dir3?

Answer 1

You are mistaken in your original assumption, which renders the rest of your question moot.

The minimum permission that a user would need on dir1 and dir2 is Traverse Directory. This will most likely be problematic to your users, though - so I would recommend Traverse Directory and List Folders. They will be able to navigate through the top two directories and get to dir3 where they have more permissions, but will not even see what files exist in the top two directories.

Permissions like Read & Execute and Modify are just collections of individual permissions. They're the first thing you see, because they're the most commonly used. If you need to get very granular (like this situation), click the Advanced button and dig into the options listed there.

Answer 2

Amazingly, if the individual has the full path to a subfolder on which they have at least R permissions, they require NO permissions on any of the parent folders, not even traverse. They can simply access it using the UNC. (They must, of course, have read permissions on the share; just not on any folders above the level they want to access).

I didn't believe this when I was told, but testing proves it out.

This is counter to what I thought I knew of permissions in the Windows world, and I suspect will be a surprise to many.

\server\folder1\folder2\folder3

If there are no permissions at all for Bilbo on folder1 and on folder2, but Bilbo has modify (for example) on folder3, \server\folder1\folder2\folder3 will take him right there, no problem.

Answer 3

One solution similar to MDMarra is set NTFS permissions as follows:

1. dir1: Grant List folder contents (Traverse folder/execute file, List folder/read data, Read attributes, Read extended attributes, Read permissions)
2. BUT select This folder only for Apply to dropdown
3. dir2: Grant List folder contents and Apply to This folder only
4. dir3: Grant desired Read/Write permissions and Apply to This folder, subfolders and files or Subfolders and files only

The end result is the user/group can read each individual parent folder and drill down to the child folder without any other folders or files.

Answer 4

So I've been testing this in the following environment as I wanted get a final, tested answer, on the bare minimum required permissions for simply traversing folders via browsing (i.e. through the Windows File Explorer). Here are the results for those who want to lock things down tight.

I have not tested this in production yet to see if there are any odd side-effects from paring down the "standard" well-tested traversal rights template of

• Traverse Folder
• List Folder
• Read Attributes
• Read Ext. Attributes
• Read Permissions

...which is basically just normal "Read And Execute" permissions limited to "This Folder". That said, small-scale testing has been completely fine so far for users simply moving, copying, and removing files on the server and users completely working off of the server copies of documents, etc.

---

Environment:

• Server: Windows 2008 R2 -- Little to not Group Policy, nothing changed relating to user rights, configured as a domain controller, AD-integrated DNS, very standard/basic setup.
• Client: Windows 7 SP1 -- Clean install in a VM, restarted between any changes to ensure the connection to the server was fully recreated each time.
• Both installations patched to at least late 2017, so likely current for anything related to permissions which are very baked-in at this point in the Windows timeline.
• This was accessing a shared folder mounted as a persistent network drive (\server\share -> S:) in the VM. Share permissions were Read+Change for Authenticated Users group which covers the test user and all others likely to ever need access at some point.
• After each change I would restart the VM, open the File Explorer, and simply browse the share normally, going down a path I knew the test user had these traversal rights on vs ones it didn't.

---

Results:

• Required on Root Folder: ListFolder-ReadData + ReadAttributes (2x permissions)
• Required on Subfolders: ListFolder-ReadData (1x permission)

• Optional: TraverseFolder--ExecuteFile

  --> This optional permission only matters if Bypass Traverse Checking User right was explicitly disallowed, as it is on by default in 99% of circumstances. Put differently, the "Bypass Traverse Checking" user right (exposed in Group Policy, not in NTFS file/folder permissions) being enabled obviates this privilege completely and effectively makes this privilege enabled everywhere by default. Note: I have not tested to see if an explicit deny of this right would, in turn, stop the Bypass Traverse Checking user right from taking effect in that particular instance, but it might).

Supplementary Info: The "Bypass Traverse Checking" user right allows someone to passively traverse to a subfolder, however many levels deep, that they have access to directly (i.e. the permissions are set on that file/folder, but not necessarily anywhere else further up the file path).