[SOLVED] Recursive chmod not working as it should

scriptkiddy · 03-08-2016, 01:12 AM

I logged in as root on my test/lab CentOS 7 box, and wanted to put read and write permissions on all home directories and subdirectories for "other" (just to test, I'm trying to learn chmod -R a bit more).

So I ran:

Code:

# chmod -R o+rwX /home

It worked, however it also put rw on files within subdirectories. Example: A simple touch test1 by root created a file under "user1" home directory as owner root, group root, with standard 644 permissions. However, after the above chmod command was run, it was 646.

Per the man of ls, the capital X is supposed to work on directories only.

Thoughts?

SK

OregonJim · 03-08-2016, 01:38 AM

Quote:

Originally Posted by scriptkiddy

the capital X is supposed to work on directories only.

Thoughts?

SK

(X): execute/search only if the file is a directory or already has execute permission for some user.

scriptkiddy · 03-08-2016, 01:47 AM

@OregonJim

I'm not sure I understand your reply. I agree that is what the manpage states. However, the test1 file had 644, which is read permissions for other. So it did not "already have execute permissions for some user", so a file with read only for other does not meet this criteria.

SK

zhjim · 03-08-2016, 01:48 AM

Never knew of the Capital X.

You can use find to get things straight

Quote:

find -type d /home -exec chmod o+rwx \{\} \;

OregonJim · 03-08-2016, 01:57 AM

Quote:

Originally Posted by scriptkiddy

@OregonJim

I'm not sure I understand your reply. I agree that is what the manpage states. However, the test1 file had 644, which is read permissions for other. So it did not "already have execute permissions for some user", so a file with read only for other does not meet this criteria.

SK

And I agree that it doesn't apply to your example case - I was just pointing out that your assumption of X only touching directories was incorrect. It will also touch files if they are already executable by anyone.

astrogeek · 03-08-2016, 02:17 AM

Quote:

Originally Posted by scriptkiddy

I logged in as root on my test/lab CentOS 7 box, and wanted to put read and write permissions on all home directories and subdirectories for "other" (just to test, I'm trying to learn chmod -R a bit more).

So I ran:

Code:

# chmod -R o+rwX /home

It worked, however it also put rw on files within subdirectories. Example: A simple touch test1 by root created a file under "user1" home directory as owner root, group root, with standard 644 permissions. However, after the above chmod command was run, it was 646.

Per the man of ls, the capital X is supposed to work on directories only.

Wrong on three counts...

First, it doesn't matter really what man ls says, you are setting perms with chmod, so be precise and see what man chmod says. And it says...

Code:

       The letters rwxXst select file mode bits for the affected users: read (r), write (w), execute (or search
       for  directories)  (x), execute/search only if the file is a directory or already has execute permission
       for some user (X)...

So, second, it will set the search bit (also called traverse bit) on all sub-directories, and set execute on files if they are already executable by at least one of owner|group|other. So, it works on directories and files, not just directories.

And third, the status of the x bit doesn't mask or set the read or write bits. So, because you told it to set o+rwX, it did indeed set all the files to rw for other, just as you asked it to do.

scriptkiddy · 03-09-2016, 11:34 PM

Hmm...

I see what you are saying astrogeek, and what the man of chmod is saying, but I'm not making the connection on one part: How did Red Hat determine that a file met the stated man page criteria?

We agree that (chmod) man page says "...execute/search only if the file is a directory or already has execute permission for some user (X)". This means there are two possible criteria:

1. File is a directory
OR
2. Already has execute permissions for some user

It was a file, so it does not meet #1. No user had execute permissions as it was 644, so it does not meet #2. That is where my little brain explodes, as the command should only set all the files to rw for other if it meets #1 or #2 above per the man page. The only possibility I can think of is that Red Hat took #1 and #2 and combined them. It applied it to the file because it was under a directory that had execute permissions on it for some user...

Maybe a better question is "How would I recursively set read write permissions only on directories (for other) using chmod command?". (I liked your alternate route there zhjim, but trying to wrap my head around this).

SK

astrogeek · 03-10-2016, 12:40 AM

Quote:

Originally Posted by scriptkiddy

I see what you are saying astrogeek, and what the man of chmod is saying, but I'm not making the connection on one part: How did Red Hat determine that a file met the stated man page criteria?

It does meet the criteria, read it again carefully.

Quote:

Originally Posted by scriptkiddy

We agree that (chmod) man page says "...execute/search only if the file is a directory or already has execute permission for some user (X)". This means there are two possible criteria:

1. File is a directory
OR
2. Already has execute permissions for some user

It was a file, so it does not meet #1. No user had execute permissions as it was 644, so it does not meet #2. That is where my little brain explodes, as the command should only set all the files to rw for other if it meets #1 or #2 above per the man page. The only possibility I can think of is that Red Hat took #1 and #2 and combined them. It applied it to the file because it was under a directory that had execute permissions on it for some user...

The part in red, no, you have not got that right.

You are trying to apply the action controlled by the X bit to select which files are affected for the r and w bits also - that is not what it says.

In the chmod -R o+rwX command, r sets the read bit, w sets the write bit, and x sets the execute bit for files, or the search bit for directories. X (upper case) also sets the execute/search bit for directories, and for regular files only if it is already set for at least one of owner|group|other.

X (upper case) does not determine which files or directories are affected by the read or write bits - they are totally independent.

As I said,

Quote:

...the status of the x bit doesn't mask or set the read or write bits. So, because you told it to set o+rwX, it did indeed set all the files to rw for other, just as you asked it to do.

Quote:

Originally Posted by scriptkiddy

Maybe a better question is "How would I recursively set read write permissions only on directories (for other) using chmod command?". (I liked your alternate route there zhjim, but trying to wrap my head around this).

You cannot do that recursively with chmod alone.

Use the find command to find all subdirectories, and the exec option to chmod them, something like this...

Code:

find /path/to/search -type d -exec chmod o+rw {} ;

You may need to escape the {} and/or ;, see man find for correct usage of that one.

scriptkiddy · 03-10-2016, 01:54 AM

Quote:

X (upper case) does not determine which files or directories are affected by the read or write bits - they are totally independent.

Ahhhhh.... Light bulb.

I think when I read the man page the word "execute" stuck out. And so in my head I thought "execute my chmod wishes"... and put the capital X as a filter for my wish (to only add rw to directories and not files).

Many thanks for the in depth explanations!

SK

astrogeek · 03-10-2016, 02:27 AM

Quote:

Originally Posted by scriptkiddy

Ahhhhh.... Light bulb.

I think when I read the man page the word "execute" stuck out. And so in my head I thought "execute my chmod wishes"... and put the capital X as a filter for my wish (to only add rw to directories and not files).

Many thanks for the in depth explanations!

I know those light bulb moments well!

You are welcome, and good luck!