Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I am having a bit of trouble understanding what the execute permission means for directories. Do I understand it correctly that anything in a directory for which a user does not have x-rights is inaccessible even if the things inside the directory gives specific rights to the user?

Or will the user still have direct access to the things in the directory, but simply cannot list what is in the directory?

(What I am really trying to understand is how safe a directory is from access from other users if they do not have x-permission for it.)

share|improve this question

3 Answers 3

up vote 7 down vote accepted

x bit for directory is also called as search bit. Actually, it enables you to access the inodes of the files listed inside the folder. So if you want to access /home/user/foo/bar.txt then you must have search access on every ancestor of bar.txt

Quoting from the page

Because directories are not used in the same way as regular files, the permissions work slightly (but only slightly) differently. An attempt to list the files in a directory requires read permission for the directory, but not on the files within. An attempt to add a file to a directory, delete a file from a directory, or to rename a file, all require write permission for the directory, but (perhaps surprisingly) not for the files within. Execute permission doesn't apply to directories (a directory can't also be a program). But that permission bit is reused for directories for other purposes.

Execute permission is needed on a directory to be able to cd into it (that is, to make some directory your current working directory).

Execute is needed on a directory to access the inode information of the files within. You need this to search a directory to read the inodes of the files within. For this reason the execute permission on a directory is often called search permission instead.

Search permission is required in many common situations. Consider the command cat /home/user/foo. This command clearly requires read permission for the file foo. But unless you have search permission on /, /home, and /home/user directories, cat can't locate the inode of foo and thus can't read it! You need search permission on every ancestor directory to access the inode of any file (or directory), and you can't read a file unless you can get to its inode.

Please read more at file permission directory section.

Update: Leo raised a very good question. If we know the inode then can we access a file from a directory having it's x bit unset? I believe, we should not be able to do so. I did not test it by c program but rather used some handy bash commands to confirm it.

user@user-desktop:~/test$ ls -lart
total 12
drwxr-xr-x 49 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x  3 user user 4096 2011-11-30 22:37 .
drwxr-xr-x  2 user user 4096 2011-11-30 22:38 level1
user@user-desktop:~/test$ ls -lart level1/
total 12
drwxr-xr-x 3 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x 2 user user 4096 2011-11-30 22:38 .
-rw-r--r-- 1 user user    8 2011-11-30 22:38 file1
user@user-desktop:~/test$ stat level1
  File: `level1'
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 808h/2056d  Inode: 95494       Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:46:16.576702105 +0530
Modify: 2011-11-30 22:38:12.386701913 +0530
Change: 2011-11-30 22:46:08.876702102 +0530
user@user-desktop:~/test$ stat level1/file1 
  File: `level1/file1'
  Size: 8           Blocks: 8          IO Block: 4096   regular file
Device: 808h/2056d  Inode: 60775       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:38:19.846701917 +0530
Modify: 2011-11-30 22:38:16.366701915 +0530
Change: 2011-11-30 22:38:16.366701915 +0530
user@user-desktop:~/test$ chmod -x level1
user@user-desktop:~/test$ stat level1/file1 
stat: cannot stat `level1/file1': Permission denied
user@user-desktop:~/test$ ls -lart level1/
ls: cannot access level1/..: Permission denied
ls: cannot access level1/.: Permission denied
ls: cannot access level1/file1: Permission denied
total 0
-????????? ? ? ? ?                ? file1
d????????? ? ? ? ?                ? ..
d????????? ? ? ? ?                ? .
user@user-desktop:~/test$ cat level1/file1
cat: level1/file1: Permission denied
user@user-desktop:~/test$ find . -inum 95494
./level1
user@user-desktop:~/test$ find . -inum 60775
user@user-desktop:~/test$ find ./level -inum 60775
find: `./level': No such file or directory
user@user-desktop:~/test$ find ./level1 -inum 60775
share|improve this answer
2  
So, if I have the inode number of a file/directory inside a directory without search-rights, I would be able to access it as long as its permissions allow it? (Getting the inode number without being able to do stat is pretty hard though I suppose.) –  Leo Nov 30 '11 at 8:22
    
@Leo I believe, we should not be able to do so. I have updated the answer. If you have a small c stub, please check it and let us know. –  Amey Jah Nov 30 '11 at 17:22
    
@AmeyJah, Actually, I bet you can. Consider what happens when you hard link a file to another directory to which you have permission. Same inode, but you can then read it. In other words, the read permission does not depend upon the system looking up all folders to which the inode might belong and seeing if they've got the x bit. Great answer though. Thanks a lot. –  user1477 May 15 at 17:34

Since you are asking for directories:

read means: read the contents, ie listing them with ls.

write means: write into the director. ie creating files or subdirectories.

execute means: enter into that directory.

read and execute permissions could be a bit tricky for directories.

For instance if you have read permissions but not execute, you can list the contents of the directory but can not drop into it. Also you can not list specific files or directories even though you know its names.

If you have execute permission but not read, you can drop into it but can not list the files directly. But, if you know names of the files or directories you can list them.

share|improve this answer
    
If you have read permission but not execute you can list (ls) the contents of the directory but cannot access (cat) the files in it. If you have execute permission but not read and you know names of the files you can access (cat) them. –  dash17291 Jul 2 '13 at 19:18

The execute permission on directories mean:

The ability to cd into this directory, and access the files in this directory.

If you do not have the x right on your directory you cannot:

  • Enter into the directory (i.e: cd)
  • Cannot access any file in this directory (even if you know the name).

Example:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ cd testdir
bash: cd: testdir: Permission denied

$ cat testdir/a
cat: testdir/a: Permission denied

$ chmod 700 testdir
$ cat testdir/a
Some text.

Read Linux File Permission Confusion pt 2 for a good introduction on the topic.

The only thing that the x permission does not seem to prevent is to access the names of the files in that directory.

Example:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ ls testdir
ls: cannot access testdir/a: Permission denied
ls: cannot access testdir/b: Permission denied
a  b
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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