I was in a directory on CentOS as user1 (root in this case) and then did su to user2 which cannot normally get to that directory due to lack of "execute" permission on a parent directory, but as user2 I was able to read what was in it just fine. I don't think this poses a security risk since I had to start out as a user with access, but is there any implication I'm not thinking of that makes this a concern?

  • Permissions only apply to the specific folder or file - they don't inherit. If you have read permissions on a folder, you can read it even if you can't get to it normally. This actually causes some issues, where people try to give too many permissions to folders "up the chain", but is intended behaviour.
    – Matthew
    Commented Feb 15, 2016 at 8:53
  • 1
    @Matthew Normally if you don't have execute (x) permission to any of the directories in the chain you're not allowed to enter the directory.
    – sa289
    Commented Feb 15, 2016 at 16:51
  • 1
    I would suggest trying to physically login as user2, and see if you can access the directory. I have noticed this on certain distributions, where su will "fallback" on the parent user if the su'ed user does not have the enough access. Im not entirely sure, this might be a convience feature to make it easier to copy/move/read files between user accounts that do not have access to each other. So the only 100% sure way to debug permissions is to logout, and then login as the user whose permissions you want to test. If you then have unintended access, then its some misconfiguration somewhere. Commented Feb 17, 2016 at 8:04

1 Answer 1


I wouldn't use the word “concerning”, but it is something you should be aware of. When you run a program with different privileges, you always need to be careful about the environment in which the differently-privileged program runs.

If the program runs with elevated privileges, it needs to be careful what environment it runs in — environment variables are a well-known risk (PATH, LD_PRELOAD, EDITOR, … to name a few among many).

If the program runs with reduced privileges, the environment needs to be careful what credentials the program receives. Credentials include users and group, but also opened file descriptors and similar things. The current directory counts as a similar thing. On this note, sudo closes all file descriptors except the standard ones (0, 1, 2), whereas (at least on Linux) su doesn't touch them.

Passing reduced-privileged processes such as a current directory or file descriptors can be useful. In your case, this allows a program to be executed as user2 and process files in that one specific directory, without allowing the program to access all the other directories that user1 can access but not user2. A classic example with file descriptors is to start a server process as root with a privileged TCP port open, and then drop privileges before executing the server application — that way the application can serve this specific privileged port but no other.

By the way, there's another way this situation (a process cannot change into its current directory) can arise: if the directory's permissions change after the process changed into that directory, that won't affect the process's current directory.

Whether this poses a security risk depends on the specific scenario. Before changing privileges, the current directory is one of the things that may need to be sanitized, like the environment, the file descriptors, etc.


You must log in to answer this question.

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