Come risolvere il difetto di progettazione di spostamento / copia NTFS?


31

Come è noto a chiunque abbia a che fare con le autorizzazioni del file server, NTFS ha un'interessante caratteristica di progettazione / difetto noto come problema di spostamento / copia.

Come spiegato in questo articolo di MS KB , le autorizzazioni per una cartella o un file non ereditano automaticamente dal padre se la cartella viene spostata e l'origine e la destinazione si trovano sullo stesso volume NTFS. Le autorizzazioni vengono ereditate se la cartella viene copiata o se l'origine e la destinazione si trovano su volumi diversi.

Ecco un breve esempio:

Hai due cartelle condivise sullo stesso volume NTFS chiamato "Tecnici" e "Manager". Il gruppo Tecnici ha accesso RW alla cartella dei tecnici e il gruppo Managers ha accesso RW alla cartella "Managers". Se qualcuno ha accesso a entrambi e sposta una sottocartella dalla cartella "Gestori" alla cartella "Tecnici", la cartella che viene spostata è ancora accessibile solo agli utenti del gruppo "Gestori". Il gruppo "Tecnici" non può accedere alla sottocartella anche se si trova nella cartella "Tecnici" e dovrebbe ereditare le autorizzazioni dall'alto.

Come puoi immaginare, ciò causa chiamate di supporto, ticket e cicli sprecati per la risoluzione di questi problemi degli utenti finali, per non parlare del ratto nidificato di autorizzazioni che puoi ottenere se gli utenti spostano spesso cartelle tra diverse cartelle / aree protette sul stesso volume.

Le domande sono:

Qual è il modo migliore per risolvere questo difetto di progettazione NTFS e come lo stai gestendo nel tuo ambiente?

So che l'articolo KB collegato parla di alcune chiavi del Registro di sistema per modificare il comportamento predefinito di Windows Explorer, ma sono lato client e richiedono agli utenti di avere la possibilità di modificare le autorizzazioni che, nella maggior parte degli ambienti, riterrei non essere un principiante se tu vuoi mantenere il controllo delle autorizzazioni del tuo file server (e della tua sanità mentale come amministratore di sistema).


2
So che l'esempio dei Manager / Tecnici è solo per illustrare il difetto, ma in alcuni casi questo è il comportamento che vorresti: se qualcuno sposta accidentalmente la cartella da Manager a Tecnici, probabilmente non vuoi che i Tecnici possano accedere esso.
Reparto - Ripristina Monica

2
Questo non è davvero un difetto, questo è il modo in cui funzionano i permessi dei file. È stato documentato dal rilascio di NTFS. Non riesco a credere che alcune persone stiano raccomandando di non utilizzare le autorizzazioni dei file e di utilizzare solo le autorizzazioni di condivisione per controllare l'accesso. Questo va contro le basi della sicurezza di un file server Microsoft. Il motivo per cui lo spostamento di una cartella / file sullo stesso volume non eredita è che la cartella / file non si sposta effettivamente sul disco, solo il puntatore che vediamo cambiare.
Michael Brown,

Risposte:


12

Il mio approccio è di non utilizzare le autorizzazioni per i file a livello di file / directory; utilizzare le autorizzazioni a livello di condivisione file e impostare l'intera unità dati del file system del server su Controllo completo di tutti (che diventa discutibile).

Nel corso degli anni (10+), ho scoperto che le autorizzazioni NTFS sono più complesse e portano a più errori. Se le autorizzazioni sono impostate in modo errato o l'eredità viene interrotta, si espongono i dati ed è difficile trovarli e vederli. Inoltre, sei esposto al problema di spostamento / copia come dici tu.

Luoghi in cui è necessario utilizzare ACL a livello di directory / file; Non conosco altra soluzione che la salute che controlla la cosa su base regolare.


10

Beh, non è proprio un difetto. Questa regola per la gestione delle autorizzazioni quando si spostano i file è in atto almeno dalla beta 2 di NT3.1 (anche se ovviamente non è ereditaria poiché è stata aggiunta solo con Windows 2000). È tanto noto quanto qualsiasi funzionalità di Windows può essere. Ho molta simpatia per il tuo punto di vista, in quanto ci possono essere pochi di noi che non sono stati bruciati da questo in una fase. Ma è qualcosa che l'amministratore di sistema impara rapidamente.

JR


6
Su questo ho discusso con Raymond Chen sul suo blog. Microsoft "vende" NTFS come avente "eredità" di autorizzazione, quindi retrocessi quando viene sollevato questo particolare nodo nell'armatura. NTFS ha l'ereditarietà delle autorizzazioni al momento della creazione del file posizionando gli ACE espliciti nei file quando vengono creati. Direi che, fintanto che la documentazione e la documentazione di marketing parlano del loro sistema di eredità come se fosse in tempo reale o la documentazione o il codice sono difettosi. Dovrebbero sceglierne uno e ripararlo.
Evan Anderson,

1
Bene, è un compromesso. Se l'ereditarietà fosse in tempo reale, ogni volta che si apriva un file nella parte inferiore di un albero profondo, il sistema operativo dovrebbe eseguire l'albero per scoprire quali sono le autorizzazioni effettive. Naturalmente il compromesso è che se cambi i permessi nella parte superiore di un albero profondo hai un'attesa troppo lunga! Active Directory non utilizza lo stesso modello?
John Rennie,

Gli oggetti AD ereditano correttamente le autorizzazioni del nuovo genitore quando vengono spostati tra i contenitori e direi che questo è il comportamento "corretto" previsto quando si spostano file / cartelle in NTFS.
David Archer,

3
@renniej: AD utilizza la vera eredità in tempo reale. Il file system di Netware lo ha fatto secoli fa. Anche NTFS avrebbe potuto farlo se Microsoft l'avesse implementato. È la "strada non presa". Ciò che mi infastidisce è che la documentazione di Microsoft relativa a: NTFS ed Explorer "gioca" come se l'eredità fosse in tempo reale (cioè bugie). Ditecelo così com'è o risolvete il comportamento in modo che sia confuso con la documentazione!
Evan Anderson,

@renniej Come disse Evan Anderson, Netware lo fece nel 1990 quando erano re. Il problema è risolvibile creando un altro indice del file system che tiene traccia dell '"elenco di visibilità". Microsoft ha scelto di non farlo, ma potrebbe presumibilmente evitarlo per una futura versione di Windows Server.
sysadmin1138

6

Usiamo NTFS da NT 3.51 e sebbene abbiamo visto questo "problema" (come quasi tutti) non ci ha causato molti problemi:

  • Diciamo sempre alle persone di copiare i file se devono spostarli da una directory condivisa a un'altra. "Tieni premuto il tasto CTRL mentre trascini e assicurati che il piccolo + sia visualizzato", è una frase comune.
  • Le nostre cartelle condivise hanno una struttura abbastanza semplice e le cartelle condivise che creiamo non si incrociano troppo spesso tra i gruppi, quindi le persone hanno maggiori probabilità di voler copiare i file in primo luogo.
  • Vediamo il problema principalmente nel nostro spazio "comune" - cartelle in cui tutti possono leggere / scrivere, ma quelle directory hanno per lo più vita breve, quindi il problema scompare quando vengono eliminate.

4

Soluzioni alternative che mi vengono in mente:

  • trovare un modo per fare in modo che le cartelle con autorizzazioni diverse si trovino su volumi NTFS diversi
  • Effettuare un'attività pianificata (una volta ogni ora o una volta al giorno a seconda della frequenza delle richieste di supporto) che attraversa le cartelle e reimposta tutte le autorizzazioni in modo che siano uguali a quelle del livello superiore. Questo non è l'ideale, tanto più se le cartelle contengono molti file, ma è qualcosa che manterrebbe il problema risolto se non esiste una buona soluzione come una correzione del registro sul lato server. Il comando che vorrai guardare si chiama 'cacls' che puoi quindi aggiungere a un file batch.

Dichiarazione di non responsabilità - Vengo da un background unix (e ho implementato l'ultimo per correggere diversi difetti delle autorizzazioni - sembra malato, ma fa il lavoro), quindi potrebbe esserci una soluzione molto migliore.


+1 - La prima risposta che Mark dà è la scelta migliore. È un dolore, ma è il modo migliore per aggirare questa stupida decisione di progettazione in NTFS 5.
Evan Anderson,

Per espandere: Questo è un posto dove i miei amici che usano SharePoint direbbero "usa SharePoint"! Allo stesso modo, i miei amici controllo-versione-utilizzo e amici-controllo-sistema-controllo-sistema indicherebbero Subversion, Documentum, ecc. E direbbero "usalo". Questa scelta di design in NTFS è una grande verruca enorme, e quasi ti fa chiederti se Microsoft effettivamente utilizza il proprio software quando devi combattere con esso nella tua rete. (Mi grida che Microsoft non usa il proprio software nello stesso modo in cui lo facciamo noi / i nostri utenti, in realtà. Deve essere bello avere una società piena di "knowledge worker".)
Evan Anderson,

1
Concordo sul fatto che idealmente potremmo separare tutte le cartelle condivise sui loro volumi, in pratica questo non è realizzabile per un ambiente di grandi dimensioni (migliaia di cartelle condivise). Inoltre, senza qualche punto di giunzione funky o voodoo symlink, questo significa perdere la possibilità di avere sottocartelle nidificate con autorizzazioni diverse su di esse.
David Archer,

1
@David: lo spostamento dei dati tra le condivisioni comporta la copia e l'eliminazione. Lo spostamento di dati all'interno di una condivisione comporterà uno spostamento. Se si rende ogni cartella condivisa la radice di una gerarchia di autorizzazioni senza sottocartelle con autorizzazioni più restrittive, si allevia il problema. Comunque brutto, comunque. (Ho un server W2K3 con 2200+ singole cartelle condivise su di esso e non vedo problemi di prestazioni ...)
Evan Anderson,

3

Quando mi muovo come amministratore uso xcopy / s / e / c / h / r / k / y - tutto a parte la proprietà del file e ACL, il che significa che l'eredità ACL entra automaticamente in gioco. Non ho mai dovuto affrontare una situazione in cui un utente spostato roba però.


2
I tuoi utenti sono vivi?
Evan Anderson,

4
A volte mi chiedo ...
Maximus Minimus,

@Even: Forse nessuno di loro è in due gruppi!
SamB,

+1 per condurre le persone allo strumento che risolve questo problema durante la manutenzione dei file (insieme a molti altri); tuttavia, XCOPY è stato ammortizzato: ROBOCOPY.EXE è il suo successore molto capace.
jnaab,

2
Ci scusiamo per il nitpicking, ma xcopy _copy_ i file (invece di _moving_ i file?) - sembra che l'autore non abbia problemi con la copia, ha solo problemi con _moving_. Potrei sbagliarmi su questo bc della mia mancanza di esperienza, quindi per favore correggimi se sbaglio (cioè usi il comando 'del' dopo aver usato 'xcopy', quindi i file vengono effettivamente 'copiati ed eliminati'! = spostato?)
colemik il

3

Uso criteri di gruppo / criteri di sicurezza / file system per tenere traccia di autorizzazioni complicate. (Non utilizzare MAI le "autorizzazioni di sostituzione" nella politica).

Pianificare un CACLS per reimpostare tutte le autorizzazioni durante la notte seguite da un gpupdate / force per riapplicare l'autorizzazione dalla politica. Funziona come un fascino.


Presumibilmente questo è solo per server Windows? Poiché i Criteri di gruppo devono essere applicati agli oggetti di dominio, questo non potrebbe essere applicato alle condivisioni di archiviazione non Windows che immagino?
Rich M

2

A partire da Windows 7 (o forse Windows Vista), le autorizzazioni per una cartella o un file ereditano dal genitore se la cartella viene spostata e l'origine e la destinazione si trovano sullo stesso volume NTFS - se un file o una cartella viene copiato tramite Explorer. In un sistema operativo precedente, è possibile utilizzare Far manager: consente di abilitare l'ereditarietà delle autorizzazioni dalla destinazione (insieme a tonnellate di altre funzionalità). Sebbene Far possa sembrare non amichevole per un utente generico.


0

Una soluzione molto semplice consiste nel comprimere i file e decomprimerli nella directory di destinazione.


Ho appena provato questo e sfortunatamente non ha funzionato. Le autorizzazioni per l'archivio zip sono diverse prima ancora di averci fatto qualcosa. Le autorizzazioni ereditate rimangono ma quelle esplicite non vengono create.
Rich M
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.