51

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?

  • 1
    The premise of the question is a bit shaky. The purpose of setting files' and directories' modes is to specify who should have what kind of access to them. This is at least notionally a characteristic of each individual file and directory itself, independent of path, and each one should therefore have the appropriate mode assigned to it. If you happen to make those decisions based on the structure of your directory tree, that does not any less mean that each individual file and directory should have the correct mode assigned to it. – John Bollinger Apr 17 at 15:31
73

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.

  • 2
    So, a short answer to the title question would be "no, you don't, just chmod'ing the top level folder is sufficient"? – Marc.2377 Apr 17 at 2:41
  • 1
    Yes, for all future accesses. – xenoid Apr 17 at 6:48
44

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.

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.
__________
1 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.)

  • Thank you for the detailed answer! I will still keep xenoid's answer "accepted" because it's so concise, but the info about hard links and working directories is very interesting! – clemisch Apr 16 at 8:35
  • Hmmm. when you copy a file, you are the owner of the copy... and you can change the flags to your heart's desire. – xenoid Apr 16 at 9:35
  • 5
    The hardlink part is interesting. Would it be possible for someone to guess the inode number and create a hardlink even after the directory rights were changed? – allo Apr 16 at 13:08
  • @xenoid: Yes, of course.  I didn’t say “If you copy your file to /Users/Public, you’ll have a problem”, because I would expect that the user wouldn’t copy a file from their secret directory to /Users/Public unless they intended to make it public.  My point is that, when you’re dealing with two things, you sometimes use a third place.  If you have a chair and a table, and you want to swap them (i.e., move them to each other’s locations), you’ll drag one of them into the middle of the room, move the second one to where the first one was, … (Cont’d) – G-Man Apr 16 at 14:43
  • 2
    @allo: Good question. I’m pretty sure that there is no program or system call that lets you create a link just by knowing the inode number.  If a user had full access to the disk (i.e., read/write access to /dev/sda1, or whatever), they could probably create such a link with a hex editor or a filesystem editor (like debugfs).  But that’s moot; anybody who has full read access to the disk can read any file; that’s why that access is typically given only to root (and possibly some other system services). – G-Man Apr 16 at 14:43
-2

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.

  • 7
    I think the OP understands what "recursive" means. What's your answer to the title question? (yes or no?) What about "practical difference"? – Kamil Maciorowski Apr 15 at 9:53
  • 6
    Sorry, what you wrote may all be true but I don't see how it answers the question. I think the question can be rephrased: after chmod g=,o= secret/, do permissions of objects inside secret/ matter? Well, do they? – Kamil Maciorowski Apr 15 at 10:11
  • Thanks for the answer! I still don't see a difference concerning the secrecy of the folder though. Could it be that you could still cd into a specific subfolder if you knew the path beforehand? – clemisch Apr 15 at 10:45
  • I just tested that and it does not seem to work. Then I really don't see any difference. As -R takes much longer (of course) for many files, I will stick to normal chmod I guess. – clemisch Apr 15 at 11:18
  • 3
    I agree with @KamilMaciorowski — you don’t seem to be saying anything wrong, but it’s not clear what you are saying. Your example is long and confusing, and you muddy the waters with your use of sudo and directories with mode 0. – Scott Apr 16 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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