Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Say I have a folder called folder in the following path:

my_path = /a/b/c/d/e/folder

and a file called file in that folder.

Then, say I run this command to remove group permissions under /a/

> chmod g-rwx -R /a/

Now, say I give +rx permissions to folder:

> chmod g+rx /a/b/c/d/e/folder

Then, if a second user in my group runs:

> ls /a/b/c/d/e/folder

or

> cat /a/b/c/d/e/folder/file 

she gets permission errors, and as far as I understand this is because I need to provide g+x access to to all the parents of folder. My question then is, when or why would it ever be useful to give +x permission to a directory whose parent does not have it?

Thanks

share|improve this question
1  
Are you sure you're running chmod +grx -R /a/b/c/d/e/folder? It's wrong, the right way to execute it is: chmod g+rx -R /a/b/c/d/e/folder –  nozimica Jun 1 '11 at 18:22
    
Thanks @nozimica. I just fixed that. –  user815423426 Jun 1 '11 at 18:26
3  
Doesn't directly answer this question, but recommended background reading: explanation of directory permissions –  Gilles Jun 1 '11 at 22:02
add comment

5 Answers 5

up vote 5 down vote accepted

Most of the time, if you want to block access and usage of an entire directory (including its subdirectory), you can do it by removing it (non-recursively) -x. Therefore, you may have left subdirectories with +x, without doing any harm.

Keeping the permissions on the subdirectories can be useful for a number of reasons (especially when -x doesn't apply to everyone but at least one user can still do something).

For example, you could block usage of the container directory temporarily, while doing other changes to the permissions within that directory structure, and then re-enable access to the whole tree in one operation (giving +x to the top level directory).

You could also have a situation where a script (not necessarily run by the owner) backs up the directory tree in a temporary location (which shouldn't be readable by others) and puts everything in a tar file, preserving the permission settings of the content of the directory.

share|improve this answer
add comment

You need +x permissions on any and all parent directories to cd or access a file in a directory.

You need +r permissions in directories in order to list files. So here's an example:

you can issue these commands to get some stuff setup:

mkdir -p /a/b

touch /a/b/{file1,file2}

cd /a

echo 1 > b/file1

echo 2 > b/file2

With no rights:

pwd
/a$ pwd
/a
/a$ chmod -rwx b
/a$ ls -l
d---------  4 mike  admin  136 Jun  1 14:44 b/
/a$ ls -l b/
ls: : Permission denied
/a$ cat b/file1
cat: b/file1: Permission denied

With execute only

/a$ chmod +x b
/a$ ls -l
total 0
d--x--x--x  4 mike  admin  136 Jun  1 14:44 b/
/a$ ls -l b
ls: b: Permission denied
/a$ cat b/file1
a
/a$ ls -l b/file1
-rw-r--r--  1 mike  admin  2 Jun  1 14:43 b/file1

Now with read:

/a$ chmod +r b/
/a$ ls -l
/a$ ls -l
total 0
dr-xr-xr-x  4 mike  admin  136 Jun  1 14:44 b/
/a$ ls -l b/
total 16
-rw-r--r--  1 mike  admin  2 Jun  1 14:43 file1
-rw-r--r--  1 mike  admin  2 Jun  1 14:43 file2

This part might be a bit confusing, but with only read and no execute, you can actually list the files in the directory, but not read the inodes metadata, so you'll get permission denied but still be able to see the list of files in a directory as below..

/a$ chmod -x b/
/a$ ls -l
total 0
dr--r--r--  4 mike  admin  136 Jun  1 14:44 b/
/a$ ls -l b
ls: file1: Permission denied
ls: file2: Permission denied
share|improve this answer
2  
Thanks @skrewler. You said: "You need +x permissions on any and all parent directories to cd or access a file in a directory", which is what I thought. My question then is: why would you ever give +x permission to a directory whose parents do not have +x permission? –  user815423426 Jun 2 '11 at 3:20
    
The only thing I can think of is if you want to make a bind mount directly there, bypassing the parent directories w/o the execute permissions. If that didn't make sense I'll show an example. –  skrewler Jun 2 '11 at 16:50
    
The above should have been more clear. A root user with the permissions to all parent directories could make this bind mount to allow other users to reach the directory. Since they could reach /a/b/c/d/e where only d or e had global execute you could make a bind mount from /mnt/d -> /a/b/c/d/e and a user could reach it by going to the mount point. It's the same idea as making a hard link to somewhere deep in a directory tree that otherwise would be unreachable. Symbolic links do not work like this though, a bind mount is needed. –  skrewler Jun 2 '11 at 16:55
add comment

You want to use non-recursive +x permissions in the situation you gave:

chmod g+x /a /a/b /a/b/c /a/b/c/d /a/b/c/d/e

(That assumes that the user is a member of each directory's group. If not, you'd have to do chmod o+x for any such directories.)

In order for a user to do ls /a/b/c/d/e/folder successfully, he must have execute permission on every directory in the path, and read permission on folder.

If you did

chmod g+x -R /a

it would work, but you'd be giving group execute permission to every file and directory under /a. That's unnecessary, and in the case of files, probably wrong.

share|improve this answer
add comment

In the particular situation you're facing, the problem is that even if folder has the proper permissions to be accessed by some user from your own group, if any of the parent folders of folder is not accessible to that user, then he will be unable to access the inner one (that which is called folder in your example).

If you execute:

chmod g-rwx -R /a/

then a and all of its children will have that permission.

When yhou execute:

chmod g+rx -R /a/b/c/d/e/folder

then folder and all of its children will have that permission as well. But, with this later command, the folders a/, a/b, and so on until a/b/c/d/e won't change their permissions.

share|improve this answer
add comment

The common case for remove the x bit on directories is to lock users in their home directories. Restricted shells have the option to not allow cd to reference absolute pathnames and to not allow execution of programs using absolute paths. They also cannot cd .. to the parent directory of their home directory and are thus effectively locked in and unable to run any programs that are not in $PATH.

share|improve this answer
add comment

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.