Perché eseguire “$ sudo chmod -R 664. "Mi viene negato l'accesso a tutte le directory interessate?

Ho una cartella di progetto che ha permessi disordinati su tutti i file. Ho avuto la brutta tendenza di impostare tutto sui permessi ottali 777 perché ha risolto tutti i problemi non legati alla sicurezza. Quindi i caricamenti FTP, i file creati da editor di testo ecc. Hanno il proprio set di autorizzazioni che rendono tutto un casino. Ho deciso di riunirmi e iniziare a utilizzare le autorizzazioni nel modo in cui dovevano essere utilizzate.

Ho pensato che 664 fosse un buon default per tutti i miei file e cartelle, e avrei semplicemente rimosso le autorizzazioni per gli altri sui file privati ​​e avrei aggiunto + x per i file eseguibili.

Il secondo ho cambiato la cartella del mio progetto in 664 tuttavia:

$ sudo chmod -R 664.  
$ ls  
ls: impossibile aprire la directory: autorizzazione negata  

Il che non ha senso per me. Ho i permessi di lettura / scrittura e sono il proprietario della cartella del progetto. La parte più a sinistra ls -lnella cartella del mio progetto è simile alla seguente:

-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 3 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
-rw-rw-r-- 1 codemonkey codemonkey ...
drw-rw-r-- 4 codemonkey codemonkey ...
drw-rw-r-- 5 codemonkey codemonkey ...

Presumo che questo abbia qualcosa a che fare con le autorizzazioni sulle directory, ma cosa?

Il bit di esecuzione è necessario per attraversare una directory * nix. Non è possibile accedere cda una directory per la quale non si dispone di autorizzazioni di esecuzione e ciò influisce su una serie di utilità in modi non ovvi se necessitano di un contesto di directory. Tenere conto:

$ cd /tmp
$ mkdir foo
$ echo baz > foo/bar
$ chmod a-x foo

# You can read the contents of the directory, but ls still complains. 
$ ls foo
ls: cannot access foo/bar: Permission denied
bar

# You can't read the file because you can't enter the directory.
$ cat foo/bar
cat: foo/bar: Permission denied

La ragione di tutto ciò è il modo in cui funziona stat (). Estratto da man 2 stat:

Non sono richieste autorizzazioni sul file stesso, ma - nel caso di stat () e lstat () - è richiesta l'autorizzazione di esecuzione (ricerca) su tutte le directory nel percorso che conducono al file.

La linea di fondo è che un ricorsivo chmodraramente farà ciò che ti aspetti e giocherà con la lettura della directory ed eseguirà autorizzazioni che possono portare a risultati imprevisti come il tuo. Trattare sempre le autorizzazioni di directory separatamente dalle autorizzazioni di file per i migliori risultati.

È necessario eseguire le autorizzazioni per le directory.

Tenere conto

sudo find -type d -exec chmod +x {} +

Aggiornamento: ecco la mia razionalizzazione di questo, apparentemente strano, uso delle autorizzazioni di esecuzione.

Unix (e quindi Linux) tratta praticamente tutto come file. Questo si estende ai dischi e a vari altri dispositivi. include anche directory.

I filesystem Unix tradizionali hanno una serie di autorizzazioni che si applicano ai file. Pertanto, i desgner di Unix hanno dovuto trovare qualcosa di utile per ogni bit di autorizzazione da eseguire quando applicato a un "file" che non era il normale file di dati.

Consideriamo le directory. Inizialmente sembra ragionevole usare solo l'autorizzazione in lettura per decidere se qualcuno può accedere alla directory, ad esempio per produrre un elenco dei file in essa contenuti, le loro dimensioni, i datestamp ecc.

Tuttavia supponiamo che tu voglia che gli utenti ordinari siano in grado di eseguire programmi in / usr / local / bin ma non vuoi che siano in grado di frugare in / usr / local per vedere cosa c'è. Se hai solo il permesso di lettura non puoi impedirlo.

Pertanto, l'autorizzazione di esecuzione, altrimenti ridondante, è stata utilizzata per controllare se la shell è autorizzata a "attraversare" una directory, ovvero intendiamo non scoprire più ciò che è necessario per poter trovare e leggere i dettagli di una sottodirectory come parte di un percorso. Ciò consente di accedere alla directory / usr / local solo per quanto è necessario per leggere i contenuti di / usr / local / bin.

Quindi + x su / usr / local significa che puoi eseguire "/ usr / local / bin / foo" Ma + r su / usr / local significa che puoi scoprire tutto ciò che è in / usr / local, incluso chi lo possiede, quali autorizzazioni ogni file ha, che dimensione era ecc.

Quanto sopra si basa su vaghi ricordi e ipotesi. Potrebbe non essere esattamente vero, ma credo che dia un'idea ragionevole del perché "eseguire" significa "in grado di attraversare".