LIAM/Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md

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:

NtfsExcludePaths=Archiv;*\Temp;Abteilung\Alt;\\server\share\legacy\*
NtfsIncludePaths=Fachbereiche\*;Shares\Produktion\*;\\server\dfs\namespace\link\*

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.

Damit bleibt das Verhalten ohne neue Konfiguration unveraendert, und spaetere Whitelist-Faelle sind sauber modellierbar.

Technische Einhaengepunkte

1. Provider-seitige Policy-Methoden

Im NTFS-Provider sollte eine kleine Policy-Schicht entstehen, zum Beispiel:

• GetAdditionalConfigurationValues(string key)
• ShouldTraversePath(string fullPath)
• MatchesPathPolicy(...)
• TryMatchPathPolicy(...)

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 bei depth > 1 weiter traversiert. Genau dort sollte vor BuildDataAreaAsync() und vor dem rekursiven Abstieg entschieden werden, ob ein Pfad ausgeschlossen ist.

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.

Bewusste Abgrenzung fuer Schritt 1

Nicht Teil des ersten Schritts:

• Umbau von cNtfsBase auf generische Filter-Callbacks
• freie Regex-Konfiguration in AdditionalConfiguration
• unterschiedliche Regeln je Klassifikationstyp

Diese Themen koennen spaeter folgen, sind aber fuer den initialen Nutzen 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:

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 ShouldTraversePath() erweitern.
4. Debug-Logging fuer Skip-Faelle einfuehren.
5. Dieselbe Policy in IsPermissionManagedFolderPath() und LoadDataArea() wiederverwenden.

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.