# LIAM NTFS AdditionalConfiguration Blacklist / Whitelist - Technischer Entwurf ## Ziel Dieses Dokument beschreibt einen kleinen technischen Entwurf, um dem NTFS-Provider ueber `AdditionalConfiguration` eine Blacklist und spaeter optional auch eine Whitelist fuer NTFS-Pfade mitzugeben. Die Policy soll klassifizierungsunabhaengig arbeiten und damit fuer Shares, DFS-Links, DFS-Namespaces und Folder dieselbe Matching-Logik verwenden. ## Ausgangslage Der NTFS-Provider verfuegt heute bereits ueber `AdditionalConfiguration`, nutzt diese im NTFS-Code aber im Wesentlichen nur fuer boolesche Feature-Flags. Die Ermittlung der DataAreas erfolgt aktuell rekursiv ueber: - Root-Aufbau in `getDataAreasAsync()` - Kind-Ermittlung in `GetChildDataAreasAsync()` - Dateisystem-Enumeration je Ebene ueber `ntfsBase.RequestFoldersListAsync(parentPath, 1)` Der bestehende Filter `ShouldIncludeDataArea()` wirkt nur auf den `DisplayName` und basiert auf `DataAreaRegEx`. Das ist fuer gezielte Ordnerausschluesse fachlich und technisch zu grob. ## Zielbild Die neue Logik soll eine explizite Pfad-Policy fuer den NTFS-Provider einfuehren. Diese Policy entscheidet fuer jeden gefundenen Pfad: - darf als DataArea materialisiert werden - darf weiter traversiert werden Ein ausgeschlossener Pfad soll weder als DataArea geliefert noch weiter traversiert werden. ## Vorgeschlagene Konfigurationsschluessel ### Aktueller Stand - `NtfsExcludePaths` - `NtfsIncludePaths` Beispiel: ```text NtfsExcludePaths=Archiv;*\Temp;Abteilung\Alt;\\server\share\legacy\* NtfsIncludePaths=Fachbereiche\*;Shares\Produktion\*;\\server\dfs\namespace\link\* ``` ## Aktueller Implementierungsstand Die nachfolgend beschriebene Path-Policy ist im NTFS-Provider inzwischen implementiert. ### 1. Materialisierung und Traversierung sind getrennt In `GetChildDataAreasAsync()` wird pro gefundenem Pfad heute getrennt entschieden: - darf der Pfad als DataArea geliefert werden - darf unterhalb des Pfads weiter traversiert werden Das ist wichtig fuer Include-Regeln. Ein Zwischenpfad darf fuer die Traversierung erlaubt sein, auch wenn erst ein tiefer liegendes Zielobjekt tatsaechlich auf der Whitelist steht. ### 2. Matching ist klassifizierungsunabhaengig Die Path-Policy arbeitet fuer: - `ServerRoot` - `ClassicShare` - `DfsNamespaceRoot` - `DfsLink` - `Folder` mit derselben Matching-Logik. Die Klassifikation bleibt fuer die fachliche Verarbeitung der DataArea relevant, nicht mehr fuer Blacklist-/Whitelist-Matching. ### 3. Relative und absolute Pfade werden parallel ausgewertet Jeder klassifizierte Pfad wird gegen mehrere Kandidaten gematcht: - relativer Pfad unterhalb von `RootPath` - normalisierter absoluter UNC-Pfad Dadurch koennen Regeln sowohl knapp relativ als auch explizit absolut formuliert werden. ### 4. Include-Regeln duerfen Traversierungs-Vorpfade freischalten Wenn `NtfsIncludePaths` gesetzt ist, darf ein Pfad auch dann traversiert werden, wenn er selbst noch nicht final matcht, aber zu einem spaeter passenden Zielpfad fuehren kann. Beispiel: ```text NtfsIncludePaths=Abteilung\IT\* ``` Dann darf `Abteilung` fuer die Traversierung erhalten bleiben, damit `Abteilung\IT\TeamA` ueberhaupt erreicht werden kann. ### 5. `LoadDataArea()` respektiert die Policy Direktes Laden eines Pfads ueber `LoadDataArea()` wird ebenfalls durch die Path-Policy eingeschraenkt. Ausnahme: - der konfigurierte `RootPath` selbst bleibt ladbar Damit kann die Filterung nicht einfach durch direktes Laden einer UID umgangen werden. ### 6. Permission-Management bleibt fachlich auf Folder beschraenkt `IsPermissionManagedFolderPath()` verwendet dieselbe generische Path-Policy, bleibt aber weiterhin nur fuer als `Folder` klassifizierte Pfade zulaessig. Die Path-Policy ist also klassifizierungsunabhaengig, das Berechtigungs-Handling selbst aber bewusst nicht. ## Matching-Regeln Empfohlene Semantik: - Trennzeichen fuer Mehrfachwerte: `;` - Auswertung case-insensitive - Leerzeichen an Eintraegen vor dem Match trimmen - Matching gegen relative Pfade unter `RootPath` und gegen normalisierte absolute UNC-Pfade - Interne Normalisierung auf konsistente UNC-/Directory-Notation - Zunaechst nur einfache Wildcards `*` unterstuetzen, keine freien Regex-Ausdruecke - Include-Regeln duerfen fuer die Traversierung auch uebergeordnete Pfade freischalten, wenn diese zu einem spaeter passenden Zielpfad fuehren Empfohlene Prioritaet: 1. Wenn keine Include-Regel gesetzt ist, sind alle Pfade grundsaetzlich erlaubt. 2. Wenn Include-Regeln gesetzt sind, sind nur passende Pfade erlaubt. 3. Exclude-Regeln werden danach angewendet und gewinnen bei Kollision. Das entspricht dem aktuell implementierten Verhalten. ## Technische Einhaengepunkte ### 1. Provider-seitige Policy-Methoden Im NTFS-Provider existiert dafuer inzwischen eine kleine Policy-Schicht, insbesondere: - `GetAdditionalConfigurationValues(string key)` - `ShouldIncludeDataArea(...)` - `ShouldTraverseDataArea(...)` - `MatchesPathPolicy(...)` - `TryMatchPathPolicy(...)` - `CanPathLeadToPattern(...)` Die Methode `IsAdditionalConfigurationEnabled()` bleibt fuer boolesche Flags bestehen und wird durch Listen-/String-Helfer ergaenzt. ### 2. Anwendung in der DataArea-Traversierung Der erste und wichtigste Einhaengepunkt ist `GetChildDataAreasAsync()`. Dort wird heute jede gefundene Ebene verarbeitet und vor `BuildDataAreaAsync()` sowie vor dem rekursiven Abstieg durch die Path-Policy geprueft. Vorteil: - geringe Eingriffstiefe - kein Umbau der allgemeinen NTFS-Basis erforderlich - fachliche Wirkung genau dort, wo DataAreas erzeugt werden ### 3. Wiederverwendung fuer Permission-Management `IsPermissionManagedFolderPath()` bleibt fachlich auf Folder beschraenkt, verwendet fuer Black-/Whitelist aber dieselbe generische Path-Policy. Damit wird vermieden, dass ein Ordner zwar nicht mehr als DataArea sichtbar ist, aber weiterhin im Permission-Flow auftaucht. ### 4. Wiederverwendung fuer `LoadDataArea()` Auch `LoadDataArea()` verwendet die Path-Policy inzwischen, damit gefilterte Pfade nicht per Direktzugriff wieder sichtbar werden. ## Offene Abgrenzung Bewusst weiterhin nicht umgesetzt: - Umbau von `cNtfsBase` auf generische Filter-Callbacks - freie Regex-Konfiguration in `AdditionalConfiguration` - unterschiedliche Regeln je Klassifikationstyp Diese Themen koennen spaeter folgen, sind fuer den aktuellen Nutzen aber nicht noetig. ## Logging Fuer ausgeschlossene Pfade sollte auf `Debug` geloggt werden: - welcher Pfad verworfen wurde - welche Regel gegriffen hat - ob der Pfad nur nicht materialisiert oder auch nicht traversiert wurde Beispiel: ```text Skip NTFS path '\\server\share\IT\_disabled' due to AdditionalConfiguration rule 'NtfsExcludePaths=IT\_disabled' ``` Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar bleiben. ## Empfohlener Umsetzungsplan 1. Listenparser fuer `AdditionalConfiguration` im NTFS-Provider einfuehren. 2. Pfadnormalisierung und Matching fuer relative sowie absolute Pfade kapseln. 3. `GetChildDataAreasAsync()` um `ShouldTraverseDataArea(...)` erweitern. 4. Debug-Logging fuer Skip-Faelle einfuehren. 5. Dieselbe Policy in `IsPermissionManagedFolderPath()` und `LoadDataArea()` wiederverwenden. Diese Punkte sind im aktuellen Implementierungsstand umgesetzt. ## Kurzfazit Die generische Path-Policy im NTFS-Provider ist klein genug fuer eine risikoarme Implementierung, passt in die vorhandene `AdditionalConfiguration`-Architektur und arbeitet ohne Sonderregeln pro Klassifikationstyp.