I have read that if the "execute" bit is not set on a directory, then you can't set that directory as your process's working directory.

But I don't understand why is that, I mean when you set the working directory of your process, you are only changing a string in your process's memory. So what does setting the working directory of your process have to do with the "execute" bit of a directory?!


From a unix kernel perspective, changing your working directory requires calling the chdir() system call.

This system call performs permissions checks in the kernel to see if the process has execute permission for that path. This is just by definition / specifications of unix.

If it doesn't have permission, then the system call returns an error. If it does, then the current working directory is changed for the process.

This state is actually represented as a pointer to the directory's inode, not a simple string. This is why you can rename a directory that a process is occupying.

Note: you can actually have execute without read on a directory. Read allows you to read the directory listing. With execute only you could cd to a directory and open a file if you already knew its name.

| improve this answer | |

Changing the working directory is slightly more involved than just changing a string in the process memory: it's actually kept in the kernel and changed by a system call. So the kernel gets to do an access control check when the working directory is changed. Also, if the x bit is not set on a directory, you cannot access any files inside the directory, regardless of what your working directory is.

The concept of "executing" a directory doesn't really exist in the way that the concept of executing a program, so calling it the "execute" bit on a directory is a bit misleading. But then, it's often called by other names, the POSIX specification calls it the "execute/search" permission, and I've seen it called the "access" permission. The GNU man pages also call it "search", e.g. chdir(2) on errors:

EACCES Search permission is denied for one of the components of path.

In the same way you can't "execute" a directory, you also can't "search" or "access" a regular file, so it's only understandable that the same bit was reused in the old times.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.