Unix/Linux equivalent of Windows' Bypass Traverse Checking

Question

Windows has a privilege called "Bypass Traverse Checking" (also known as SeChangeNotifyPrivilege). It allows the system to bypass ACL checks in parent objects so a user can [potentially] access a child object.

An example would probably be helpful:

<file system>
  |
  +-- john.doe
      |
      +-- public

In the example above, one would normally clamp down directory john.doe so that he has full control (and perhaps his group has read access). However, Doe's public directory is world readable so that anyone can see what he's sharing.

In Windows, Bypass Traverse Checking would be used to facilitate the above scenario.

Does Unix/Linux offer the equivalent of Windows Bypass Traverse Checking? If so, what is it?

If not, how does one provide access to the public directory without opening security holes in parent directory?

---

Interestingly, all my Ubuntu machines de-clamp the home directory so that anyone can access it on the way to the public directory, even the Guest account!!! And the Guest account is allowed to probe root's directory, too. But Guest accounts on desktops and servers is a whole 'nother can of worms...

---

And I recently came across this from Cryptree: A Folder Tree Structure for Cryptographic File Systems. I think the claim was not quite correct (as "Bypass Traverse Checking" demonstrates):

Upward Inheritance of Access Rights: Explicitly granted access to a folder implies inherited access to the names of the folder’s ancestor folders. For example, when granting Alice recursive access to a folder documents/ that resides in /bob/projects/, Alice should automatically be allowed to see the names of its ancestor folders /bob/ and /bob/projects/. Without being able to see the parent folders’ names, it would not be possible for her to reconstruct the correct path of documents/.

Answer 1

Linux doesn't have an exact equivalent of “bypass traverse checking”. It uses other means to achieve the same policies.

Traditionally, a user's home directory is publicly readable. Users can create subdirectories for private files, and make them private. A nice property of Unix permissions (including modern ACL schemes) is that if any component of a path is private, the file is private, no matter what the permissions on the file are (i.e. there is no way to bypass traverse checking…), so there's no risk of a file in a private directory being accidentally made public. Applications create files according to the umask by default; if the user sets a umask of 077 then their files will be private by default (the default umask is traditionally 022, making files publicly readable but not writable). Applications that expect the file contents to be private (e.g. emails) create private files regardless of the umask.

There is one way in which a file in a private directory can be accessed by another user: when a file is moved, any process that has it opened retains its access to the file. So a file created in a private directory is secure, but a file that was moved there might still be opened. This only matters if you write more data to the file after moving it.

It's possible to create a view of a directory in another location, potentially with different permissions. The permissions on the view are not affected by the permissions on the traversal to the actual directory, only on the permissions on the traversal to the location of the view, the permissions on the directory itself and its files, and if applicable the parameters of the view. Views can be created with the bindfs filesystem or with Linux's bind mount. See Allow non-root process to access all home directories without compromising security?, Allow a user to read some other users' home directories and How to allow access to only one NTFS folder of already mounted partition for specific user? for examples.

Answer 2

To some extent:

In the Unix permission model, the r bit on a directory allows listing its content, and the x bits allows getting a handle to the directory. A handle allows you to reference files and directories in that directory if you know their name, and using them is subject to the permissions on the inode of that object.

So for the scenario you describe, you would give x permission to others, allowing everyone to pass through this directory on their way to the public directory -- everything else in that directory however needs to have permissions set to lock out others, obviously.

This is (or used to be) a common configuration for the public_html directory in the user's home directory.