Cambiare i permessi sulla directory è probabilmente il modo migliore per andare, sì. Oltre ad essere relativamente facile, ha il vantaggio di agire più come la maggior parte dei sistemi di tipo Unix, dove i nuovi file (in questo caso scaricati) non sono eseguibili di default. Win32 non ha l'equivalente di umask , ma puoi fingere usando l'ereditarietà di directory (che Unix non usa per lo più).
Alcune cose da tenere a mente quando fai questo:
- Gli ACL NTFS supportano sia le voci "allow" che "deny", sia per gli utenti che per i gruppi. Vengono valutati nel seguente ordine: utente deny > l'utente autorizza > gruppo nega > gruppo consentire. In altre parole, una negazione su un utente specifico vince sempre, ma un permesso su un utente specifico sconfigge un gruppo su cui l'utente appartiene, ma se l'utente non ha né consentito né negato le voci, allora se qualcuno dei gruppi dell'utente ha un nega poi questo trionfo qualsiasi consente che il gruppo dell'utente abbia. Se né l'utente né alcuno dei gruppi dell'utente ha consentito o negato le voci, l'impostazione predefinita è di non consentire (negare).
- NTFS supporta l'ereditarietà delle autorizzazioni, dove un oggetto (file, directory, reparse point, ecc.) può avere alcune autorizzazioni ereditate dal suo contenitore (directory). In effetti, questo è il modo in cui vengono impostate la maggior parte delle autorizzazioni in NTFS; relativamente pochi oggetti hanno ACL espliciti. Si noti inoltre che un oggetto può disabilitare l'ereditarietà (non ottiene gli ACL del proprio contenitore), un ACL può essere non-ereditabile (gli oggetti contenuti non lo otterranno, anche se hanno ereditato abilitato) e un ACL può essere ereditato- solo (il che significa che non si applica al contenitore, solo a quelli del suo contenuto che consentono gli ACL ereditati).
- Seguendo la regola di "battiti specifici generali", un ACL esplicito su un oggetto sovrascrive l'ACL ereditato se vi sono conflitti. Pertanto, anche se la cartella Download non fornisce il suo contenuto per l'autorizzazione Execute (o, anzi, lo nega), qualsiasi specifico file all'interno di Download potrebbe comunque ottenere tale autorizzazione tramite un ACL esplicito.
- NTFS, come la maggior parte dei file system, ri-utilizza il bit di autorizzazione Execute su un file come il bit di autorizzazione della directory di attraversamento. Di conseguenza, rimuovere (o negare) Execute nella directory Download normalmente impedisce all'utente di accedere a qualsiasi suo contenuto (è possibile elencarli, purché si disponga ancora dell'autorizzazione di lettura, ma non è possibile leggerli o scriverli, ecc.) . Tuttavia, Windows per impostazione predefinita ignora i controlli di autorizzazione Traverse (è possibile disattivare questo comportamento, se lo si desidera), facendo affidamento su Read / Write / etc. anziché. Questo comportamento significa che puoi avere cose strane, come una struttura di directory
A\B\C\D.txt in cui l'utente non ha affatto accesso a A, B o C, ma può leggere e perfino modificare D.txt a patto che le autorizzazioni su quel file lo consentano tale accesso (e l'utente conosce il percorso esatto). Significa anche che, per le directory, il bit Execute / Traverse non fa praticamente nulla se non per scopi di ereditarietà.
- Mentre l'autorizzazione Execute sui file in formato PE (.EXE, .DLL, .SYS, ecc.) funziona come ci si aspetterebbe, l'azione predefinita su molti altri tipi di file "eseguibili" che vengono effettivamente eseguiti tramite qualche programma (.BAT, .JAR, .PY, .JS, possibilmente anche .MSI. Ecc.) Saranno ignorati dal sistema operativo; tali file hanno solo bisogno di permessi di lettura, e solo i loro interpreti / runtime / ecc. hai bisogno di autorizzazioni Execute.
Con tutto ciò che detto: l'impostazione di un permesso Nega su Execute / Traverse per il gruppo Everyone nella directory Download (e assicurandosi che si tratti di un permesso ereditabile, anche se di default dovrebbe essere) dovrebbe fare principalmente quello che vuoi.