Ai-je vraiment besoin d'un chmod récursif pour restreindre l'accès à un dossier ?

Il va sans dire que, si vous avez créé un fichier il y a deux jours (avec un mode de lecture publique), et que quelqu'un a lu le fichier hier, ou en a fait une copie, alors il n'y a rien que vous puissiez faire aujourd'hui pour rendre ce fichier privé.

xénoïde dit (de manière un peu simpliste) que, si vous supprimez les autorisations de groupe et autres de votre répertoire (aujourd'hui, maintenant), "tout ce qui se trouve en dessous devient inaccessible, et vous n'avez pas besoin de faire un changement récursif."  Je suis d'accord que, si vous chmod votre répertoire (de premier niveau) de manière appropriée, personne d'autre que vous-même 1 pourra y accéder à l'avenir (c'est-à-dire à partir de maintenant).  Mais il y a quelques inconvénients.

Liens durs

Vous vous souvenez du fichier que vous avez créé il y a deux jours ?  Supposons que votre adversaire ait créé un lien dur vers ce fichier hier (au lieu de le copier). (au lieu de le copier). Si vous chmod seulement votre répertoire (de premier niveau), alors ce fichier continuera à avoir les permissions de lecture publique que vous avez attribuées lorsque vous l'avez créé, et donc le méchant sera toujours en mesure de le lire dans le futur - (potentiellement) même si vous le modifiez par la suite.  Si vous effectuez une opération récursive chmod , qui sécurisera les permissions sur le fichier, qui affectera le lien.   Le méchant sera toujours capable de faire ls -l sur elle, pour qu'ils puissent voir quand tu le changes, et quelle est sa taille, mais ils ne seront pas en mesure de le lire à nouveau.

Répertoire de travail

Supposons que, selon votre secret répertoire, vous avez un  plans et il est également accessible en lecture publique.  Et supposons que, il y a cinq minutes, le méchant a ouvert une fenêtre de terminal et a dit

cd /home/clemisch/secret/plans

Maintenant, après avoir fait le chmod sur secret , le répertoire de travail du méchant est toujours /home/clemisch/secret/plans , et ils peuvent continuer à lister ce répertoire et accéder aux fichiers qui s'y trouvent, potentiellement pour toujours.  Bien sûr, une fois qu'ils cd ailleurs, ou fermez cette fenêtre, ou se déconnecter, ou la machine est redémarrée, alors ils perdent l'accès.

Si vous faites une récursive chmod qui sécurisera les permissions sur tous les fichiers et tous les répertoires, faisant perdre l'accès au squatter immédiatement.

Ce n'est peut-être pas un très grand risque si la machine est un ordinateur personnel auquel on accède uniquement par la console.  Mais, si le malfaiteur a pu laisser une  screen ou  tmux session en arrière-plan, alors ils pourraient utiliser cette attaque.  Et, si la machine supporte ssh (ou un autre accès à distance ; peut-être même que FTP serait suffisant), cette attaque peut être utilisée.

L'erreur humaine

Comme l'a souligné xenoid dans sa réponse : Si vous faites une récursive chmod sur secret aujourd'hui, et puis après-demain, tu as accidentellement chmod (seulement) le répertoire de premier niveau à 755, alors vous serez toujours protégé par le système récursif actuel. chmod - tous les fichiers et répertoires sous secret sera toujours illisible.  (Bien sûr, si vous créez un nouveau dans secret demain, et que vous l'autorisez à être publiquement lisible, alors elle sera exposée quand vous ouvrirez les permissions sur le secret annuaire.  Mais ce serait vrai que l'on soit aujourd'hui chmod était récursif ou non).

mazunki a fait un commentaire "Je crois cp porte des permissions".  Je ne suis pas sûr de ce qu'ils voulaient dire, mais considérez ce scénario.  Vous voulez faire un diff entre deux fichiers :

• secret/plans/the/quick/brown/fox/file1
• secret/jumps/over/the/lazy/dog/file2

Mais vous ne savez pas exactement où se trouvent ces fichiers, et vous devez fouiller pour les trouver.  Vous pourriez être tenté de faire

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

Si vous faites ça, alors /tmp/file1 bénéficieront de la même protection que secret/plans/the/quick/brown/fox/file1 - donc c'est une autre raison de faire le récursif chmod aujourd'hui.

UNE dernière chose

Si le méchant a ouvert un de vos fichiers secrets il y a cinq minutes, et le garde ouvert, il sera capable de le lire dans le futur. - potentiellement même si vous le modifiez.  La bonne nouvelle est qu'il s'agit d'une attaque assez délicate à exécuter - le méchant doit y avoir réfléchi, avant que vous ne fassiez l'opération. chmod .  La mauvaise nouvelle est qu'il est très difficile de se défendre contre cette attaque - un chmod récursif ne sera d'aucune aide.
__________
1 et, bien sûr, les utilisateurs/processus privilégiés.

P.S. Vous pouvez raccourcir un peu votre commande : chmod go= est équivalent à chmod g=,o= .  (Cela ne rendra pas la récursive chmod plus rapidement, bien sûr).

Récursif chmod affecte également tous les sous-répertoires et dossiers, et pas seulement le dossier lui-même.

.:
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

Si vous ne donnez pas explicitement l'accès à . vous ne serez pas en mesure de lire le contenu du dossier.

[] ~:~/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  

De même, vous ne pourrez pas cd dans les sous-répertoires dudit dossier, à moins que vous n'ayez explicitement +x les.