Cfxtrjtrk

If I want to restrict access to a folder secret on a shared machine, do I really need recursive chmod on the folder

chmod -R g=,o= secret

or is chmod on the folder sufficient?

chmod g=,o= secret

What's the practical difference?

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 yourself¹
will be able to get into it in the future (i.e., from now on). 
But there are some gotchas.

Hard links

Remember that file you created two days ago? 
Suppose that your adversary made a hard link to that file yesterday
(instead of copying it).
If you 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 chmod,
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.

Working directory

Suppose that, under your secret directory,
you have a plans directory, and it also it publicly readable. 
And suppose that, five minutes ago,
the bad guy opened a terminal window and said

cd /home/clemisch/secret/plans

Now, after you do the chmod on secret,
the bad guy’s working directory is still  /home/clemisch/secret/plans,
and they can continue to list that directory and access the files there,
potentially forever. 
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 screen or tmux session
in the background, then they could use this attack. 
And, if the machine supports ssh
(or other remote access; maybe even FTP would be enough),
this attack can be used.

Human error

As xenoid pointed out in their answer:
If you do a recursive chmod on secret today,
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 chmod —
all the files and directories under secret will still be unreadable. 
(Of course, if you create a new file in secret tomorrow,
and you allow it to be publicly readable, then it will be exposed
when you open the permissions on the secret directory. 
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:

• secret/plans/the/quick/brown/fox/file1


• secret/jumps/over/the/lazy/dog/file2

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
as secret/plans/the/quick/brown/fox/file1 —
so that’s another reason to do the recursive chmod today.

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 chmod. 
The bad news is that this attack is very difficult to defend against
— a recursive chmod won’t help.

__________
¹ and, of course, privileged users / processes

P.S. You can shorten your command a little:
chmod go= is equivalent to chmod g=,o=. 
(That won’t make the recursive chmod any faster, of course.)

Recursive chmod affects all subdirectories and folders too, not just the folder itself.

.:

total 16

drwxrwxr-x  4 mazunki mazunki 4096 april 15 11:42 .

drwxr-xr-x 35 mazunki mazunki 4096 april 15 11:42 ..

d---------  3 mazunki mazunki 4096 april 15 11:46 a

d---------  2 mazunki mazunki 4096 april 15 11:42 b



./a:

total 12

d--------- 3 mazunki mazunki 4096 april 15 11:46 .

drwxrwxr-x 4 mazunki mazunki 4096 april 15 11:42 ..

-----w---- 1 mazunki mazunki    0 april 15 11:42 a

dr-xr-xr-x 2 root    root    4096 april 15 11:46 aa

-----w---- 1 mazunki mazunki    0 april 15 11:42 b



./a/aa:

total 8

dr-xr-xr-x 2 root    root    4096 april 15 11:46 .

d--------- 3 mazunki mazunki 4096 april 15 11:46 ..



./b:

total 8

d--------- 2 mazunki mazunki 4096 april 15 11:42 .

drwxrwxr-x 4 mazunki mazunki 4096 april 15 11:42 ..

-----w---- 1 mazunki mazunki    0 april 15 11:42 a

-----w---- 1 mazunki mazunki    0 april 15 11:42 b

 ~:~/test ▶ 

 ~:~/test ▶ 

 ~:~/test ▶ sudo chmod -R +w a

 ~:~/test ▶ 

 ~:~/test ▶ 

 ~:~/test ▶ sudo ls -alR 

.:

total 16

drwxrwxr-x  4 mazunki mazunki 4096 april 15 11:42 .

drwxr-xr-x 35 mazunki mazunki 4096 april 15 11:42 ..

d-w-------  3 mazunki mazunki 4096 april 15 11:46 a

d---------  2 mazunki mazunki 4096 april 15 11:42 b



./a:

total 12

d-w------- 3 mazunki mazunki 4096 april 15 11:46 .

drwxrwxr-x 4 mazunki mazunki 4096 april 15 11:42 ..

--w--w---- 1 mazunki mazunki    0 april 15 11:42 a

drwxr-xr-x 2 root    root    4096 april 15 11:46 aa

--w--w---- 1 mazunki mazunki    0 april 15 11:42 b



./a/aa:

total 8

drwxr-xr-x 2 root    root    4096 april 15 11:46 .

d-w------- 3 mazunki mazunki 4096 april 15 11:46 ..



./b:

total 8

d--------- 2 mazunki mazunki 4096 april 15 11:42 .

drwxrwxr-x 4 mazunki mazunki 4096 april 15 11:42 ..

-----w---- 1 mazunki mazunki    0 april 15 11:42 a

-----w---- 1 mazunki mazunki    0 april 15 11:42 b

If you don't explicitly give access to ., you won't be able to read the contents of the folder.

 ~:~/test ▶ ls -l

total 8

drwxr-xr-x 3 mazunki mazunki 4096 april 15 11:46 a

d--------- 2 mazunki mazunki 4096 april 15 11:42 b

 ~:~/test ▶ 

 ~:~/test ▶ 

 ~:~/test ▶ sudo chmod +xxx b

 ~:~/test ▶ cd b

 ~:~/test/b ▶ ls

ls: cannot open directory '.': Permission denied

 ~:~/test/b ▶ sudo chmod +xxx .

 ~:~/test/b ▶ ls

ls: cannot open directory '.': Permission denied

 ~:~/test/b ▶ sudo chmod +rrr .

 ~:~/test/b ▶ ls

a  b

 ~:~/test/b ▶ 

Likewise, you won't be able to cd into subdirectories of said folder unless you explicitly +x them.