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 Ordner mitzugeben.

Im ersten Schritt soll damit die Enumeration von Unterordnern fuer getDataAreasAsync() gezielt eingeschraenkt werden, ohne bestehende Konfigurationen zu brechen.

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 Unterordner:

• darf als DataArea materialisiert werden
• darf weiter traversiert werden

Fuer Schritt 1 reicht es, wenn ein ausgeschlossener Ordner weder als DataArea geliefert noch weiter traversiert wird.

Vorgeschlagene Konfigurationsschluessel

Minimal fuer Schritt 1

• NtfsExcludeFolderNames
• NtfsExcludeRelativePaths

Beispiel:

NtfsExcludeFolderNames=Temp;Archiv;System Volume Information
NtfsExcludeRelativePaths=Abteilung\Alt;IT\_disabled

Erweiterbar fuer Schritt 2

• NtfsIncludeFolderNames
• NtfsIncludeRelativePaths

Beispiel:

NtfsIncludeRelativePaths=Fachbereiche\*;Shares\Produktion\*

Matching-Regeln

Empfohlene Semantik:

• Trennzeichen fuer Mehrfachwerte: ;
• Auswertung case-insensitive
• Leerzeichen an Eintraegen vor dem Match trimmen
• Pfade relativ zu RootPath vergleichen
• Interne Normalisierung auf konsistente UNC-/Directory-Notation
• Zunaechst nur einfache Wildcards * unterstuetzen, keine freien Regex-Ausdruecke

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)
• MatchesFolderNamePolicy(string folderName)
• MatchesRelativePathPolicy(string fullPath)

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. Spaetere Wiederverwendung fuer Permission-Management

Aktuell erlaubt IsPermissionManagedFolderPath() jeden als Folder klassifizierten Pfad.

Wenn ausgeschlossene Ordner spaeter auch nicht mehr fuer Berechtigungs-Provisionierung oder Traverse-Gruppen bearbeitet werden sollen, sollte dieselbe Policy dort wiederverwendet werden.

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 fuer Shares, DFS-Links und Folder
• Policy-Auswertung fuer LoadDataArea() ausserhalb des normalen Traversal-Falls

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 'NtfsExcludeRelativePaths'

Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar bleiben.

Empfohlener Umsetzungsplan

1. Listenparser fuer AdditionalConfiguration im NTFS-Provider einfuehren.
2. Pfadnormalisierung und relatives Matching gegen RootPath kapseln.
3. GetChildDataAreasAsync() um ShouldTraversePath() erweitern.
4. Debug-Logging fuer Skip-Faelle einfuehren.
5. Optional in einem zweiten Schritt dieselbe Policy in IsPermissionManagedFolderPath() wiederverwenden.

Kurzfazit

Fuer den ersten Schritt ist eine blacklist-basierte Pfad-Policy im NTFS-Provider der pragmatischste Weg.

Sie ist klein genug fuer eine risikoarme Implementierung, passt in die vorhandene AdditionalConfiguration-Architektur und laesst sich spaeter ohne Bruch zu einer echten Include-/Exclude-Policy ausbauen.