Do I really need recursive chmod to restrict access to a folder?
For a directory, "read" access lets you list the contents, and "execute" access lets your traverse the directory to open one of its children (file or subdirectory). So if you remove:
- just the read access, people can still access subdirectories by guessing their names
- just the execute flag, people can still list the names of the contents even if they cannot access them, and this can still be revealing
- both read and execute privileges on a directory, anything below it becomes unreachable, and you don't need to make a recursive change.
Of course if you make a recursive change, an accidental non-recursive reset of the access rights to the top directory will have less consequences.
It goes without saying that, if you created a file two days ago (with a publicly readable mode), and somebody read the file yesterday, or made a copy of it, then there’s nothing you can do today to make that file private.
xenoid says (somewhat simplistically) that,
if you remove group and other permission from your directory (today, now),
“anything below it becomes unreachable,
and you don't need to make a recursive change.”
I agree that, if you
chmod your (top-level) directory appropriately,
nobody but yourself1
will be able to get into it in the future (i.e., from now on).
But there are some gotchas.
Remember that file you created two days ago?
Suppose that your adversary made a hard link to that file yesterday
(instead of copying it).
chmod only your (top-level) directory,
then that file will continue to have the publicly readable permissions
you assigned when you created it,
and so the bad guy will still be able to read it in the future
— (potentially) even if you subsequently modify it.
If you do a recursive
that will secure the permissions on the file,
which will affect the link.
The bad guy will still be able to do
ls -l on it,
so they’ll be able to see when you change it, and how big it is,
but they won’t be able to read it again.
Suppose that, under your
you have a
plans directory, and it also is publicly readable.
And suppose that, five minutes ago,
the bad guy opened a terminal window and said
Now, after you do the
the bad guy’s working directory is still
and they can continue to list that directory and access the files there,
Of course, once they
cd elsewhere, or close that window,
or log out, or the machine is rebooted, then they lose access.
If you do a recursive
chmod, that will secure the permissions
on all the files and all the directories,
causing the squatter to lose access immediately.
This might not be a very big risk if the machine is a personal computer
that is accessed only through the console.
But, if the bad guy might have left a
in the background, then they could use this attack.
And, if the machine supports
(or other remote access; maybe even FTP would be enough),
this attack can be used.
As xenoid pointed out in their answer:
If you do a recursive
and then the day after tomorrow you accidentally
chmod (only) the top-level directory back to 755,
then you will still be protected by today’s recursive
all the files and directories under
secret will still be unreadable.
(Of course, if you create a new file in
and you allow it to be publicly readable, then it will be exposed
when you open the permissions on the
But that would be true
no matter whether today’s
chmod was recursive or not.)
mazunki made a comment, “I believe
cp carries permissions.”
I’m not sure what they meant, but consider this scenario.
You want to do a
diff between two files:
But you aren’t sure exactly where those files are, and you have to poke around to find them. You might be tempted to do
cd plans cd the/quick # looking for file1 cd brown/fox # found it! cp file1 /tmp cd ../../../../.. cd jumps/over cd the # looking for file2 cd lazy/dog # found it! diff /tmp/file1 file2
If you do this, then
/tmp/file1 will have the same protection
so that’s another reason to do the recursive
ONE more thing
If the bad guy opened one of your secret files five minutes ago,
and keeps it open, they will be able to read it in the future
— potentially even if you modify it.
The good news is that this is a somewhat tricky attack to execute —
the bad guy has to have put some thought into it, before you do the
The bad news is that this attack is very difficult to defend against
— a recursive chmod won’t help.
1 and, of course, privileged users / processes
P.S. You can shorten your command a little:
chmod go= is equivalent to
(That won’t make the recursive
chmod any faster, of course.)