From f9daba1bb6323f09c17db6fd35b5e0471a4275dd Mon Sep 17 00:00:00 2001 From: Meik Date: Sun, 29 Mar 2026 22:27:00 +0200 Subject: [PATCH] Add NTFS blacklist whitelist concept --- ...nalConfiguration_BlackWhitelist_Konzept.md | 148 ++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md diff --git a/Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md b/Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md new file mode 100644 index 0000000..e65c68e --- /dev/null +++ b/Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md @@ -0,0 +1,148 @@ +# 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: + +```text +NtfsExcludeFolderNames=Temp;Archiv;System Volume Information +NtfsExcludeRelativePaths=Abteilung\Alt;IT\_disabled +``` + +### Erweiterbar fuer Schritt 2 + +- `NtfsIncludeFolderNames` +- `NtfsIncludeRelativePaths` + +Beispiel: + +```text +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: + +```text +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.