A unix directory tree has NTFv4 ACLs configured to allow an unprivileged account traversal on all dirs (but no other ACL granting further rights on any file/dir anywhere

In such a case, is it completely safe to universally grant directory traversal right to everyone (setfacl everyone@:x:d:allow /path_to_mountpoint or similar), or can this be somehow exploited even despite there being no other ACLs set?

I'm figuring that in the absence of any other permission/ACL allowing other rights, this should result in an absence of any right to read, modify or control any object traversed to. Thus the traversal right is valid but in practice it's utterly useless / sterile.

In this context I categorise "exploit" strictly, and even the ability to list files in a dir (that didn't have other additional ACLs set on it) would count as "exploiting" since it's more than just traversal.

In that sense, can bare traversal ACLs be exploited, or is this a "safe" right (including in the sense of file privacy) to give untrusted/unprivileged/guest accounts even on paths one doesn't want them to make use of?


I'm mainly thinking of a file server's data store on FreeBSD ZFS, but I guess it's similar on most unixes.

The use case is: suppose I want a specific unprivileged user to access only a specific nested dir within my data directory. Rather than setting traversal for that user on all parent dirs to reach that path, it would be administratively easier if it's secure, to

  1. Grant universal traverse rights to everyone on the entire data dir, inherited to all dirs, but then
  2. Control actual use/access/scanning by setting read/write/modify ACLs on files+dirs they are allowed to use, while setting no rights, or explicit deny rights, on every other ACL flag on all other dirs/files (other than just "x" on dirs).

If traversal can't be exploited, then the traversal right is sterile and useless unless combined with a target path/file that the user actually has some other ACLs for. But is that correct, or is it subtly loophole-y?

1 Answer 1


Granting traversal only (x permission on directories, and nothing else) doesn't let someone do much, but it does create some risks.

With x permission on directories, a user can check whether a file exists. Without the r permission on the directory, the user can't list files, but if they guess a file name, they can test whether there is a file by that name. This usually doesn't leak a lot of data, but it can be a privacy violation.

Beyond this, there is a risk that some file or directory inside the tree is not protected. It's pretty common to have world-readable files lying around. That's safe as long as they're under a directory that unauthorized users can't traverse. If you give traversal permission to everyone, then everyone can access those world-readable files. The same risk exists with world-writable or group-writable files.

Rather than give traversal permission to the toplevel directory, it's safer to expose selected subdirectories. As usual, it's safer to whitelist known public data than blacklist known confidential data. You can expose a subdirectory of a private directory through a bind mount. On FreeBSD, you can create a bind mount with nullfs (built in) or bindfs (FUSE).

  • 1
    Those are good points, and the kind of answer I hoped for. Now I feel I have some understanding of how and where risk may emerge with this. (As an aside, inherited ACLs do require root use to change protection within the fs, but yes mistakes can happen.) Good points.
    – Stilez
    Apr 15, 2018 at 6:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .