FileSystemWatcher che supera le autorizzazioni del file system

Question

Durante la sperimentazione con FileSystemWatcher, ho scoperto che in qualche modo supera le autorizzazioni del mio account utente per file e cartelle e genererà eventi di modifica con informazioni su cosa è cambiato in file e cartelle che non si t ho anche accesso a.

Ho due domande a riguardo:

1) Perché accade questo?
2) Si tratta di un problema nella configurazione AD? come lo aggiusto ?
3) C'è un modo per raccogliere questi file, o persino crearne uno FileSystemInfo per ottenere maggiori informazioni sui file (non solo sulle modifiche apportate su di essi)?

Per quanto ho provato, solo il sistema immunitario FileSystemWatcher alle restrizioni, che non può eseguire qualsiasi altra cosa su di esso, ecco una lista di quello che ho provato:

• File.Exists
• Directory.Exists
• esempio FileInfo sul file trovati
• DirectoryInfo esempio sul file trovati
• File.Copy
• File.Delete

---

Aggiornamento: Ho provato la soluzione di Helge, con qualcosa simile a quello che ha sugested, non attraverso API di Windows', ma attraverso il prompt dei comandi:

robocopy/B myserver \ cartella \ c: \ somefolder

Nome del comando migliore di sempre.

È possibile verificare attraverso robocopy che/B sta per "modalità di backup", che è ciò che Helge suggerito che sarebbe la causa di questa sicurezza superando.

Cercherò nulla, voglio scoprire che cosa causa esattamente FileSystemWatcher per essere in grado di guardare le cartelle che non ho il permesso di aprire. Sapendo perché, voglio imparare sia come bloccare FileSystemWatcher, sia come raccogliere i file trovati.

Farei un sondaggio se fossi con il mio account personale. Per favore, qualcuno può aiutarmi? Scriverò un post sul blog sulla soluzione, tra le altre cose che potrebbe aiutare chiunque abbia lo stesso dubbio in futuro.

Answer 1

Secondo this answer on SO, FileSystemWatcher si basa sulla funzione API ReadDirectoryChangesW. Se ciò è vero, spiega il comportamento che hai visto - e perché non è un buco di sicurezza.

Come documented on MSDN ReadDirectoryChangesW richiede il privilegio SeBackupPrivilege (richiesto dal parametro FILE_FLAG_BACKUP_SEMANTICS su CreateFile). Se un file viene aperto in tale modalità, l'handle restituito garantisce l'accesso completo al file, aggirando i controlli di accesso. Questa funzione è progettata per backup programs che deve essere in grado di leggere tutto sul disco indipendentemente dalle autorizzazioni.

Questo non è un buco di sicurezza perché il privilegio SeBackupPrivilege che è necessario affinché questo funzioni è concesso di default solo agli amministratori.Gli amministratori, e in effetti chiunque abbia accesso fisico a una macchina, è sempre in grado di prendere il controllo e leggere ogni file, a meno che non sia crittografato.

Per quanto riguarda quali funzioni possono essere utilizzate per accedere ai file in modalità di backup: Esiste almeno BackupRead per la lettura. L'enumerazione è facilmente possibile con FindFirstFile/FindNextFile. Ovviamente ciò richiede la vera API di Windows, non le funzioni di file system .NET danneggiate.