Rechte von Dateien ermitteln

[MaBuSE]

Hallo,
nach einigem Suchen und nichts passendem Finden frage ich Euch:

Folgendes Problem:
Ich habe in einem Verzeichnis x Dateien (oder Verzeichnisse)

Ich müsste nun ermitteln, ob ich auf diese Dateien Zugriff habe.

Code:

z.B.
Datei1 - kein Zugriff
Datei2 - nur Lesen
Datei3 - Lesen und Schreiben

Ich möchte es nicht "ausprobieren" in dem ich die Dateien öffnen, es gibt ja APIs um die Rechte auszulesen.

Der 2. Schritt wäre herauszufinden, warum man Zugriff hat.
Also die globale Gruppe zu ermitteln, der man angehört und die entsprechende Rechte auf die Datei
definiert.

Ziel ist es eine Funktion zu schreiben, die die Rechte zurückgibt:

Delphi-Quellcode:

type 
  TRight = rNone, rRead, rReadWrite;

function GetFileRight(Filename: string): TRight;
function GetFileRightGroupName(Filename: string): string;

Kann jemand helfen?

Danke im Voraus
MaBuSE

[Dezipaitor]

In 90% der Fälle besitzen Dateien keine eigenen Rechte, sondern bekommen sie vom übergeordneten Ordner vererbt, der sie meistens auch wieder vererbt bekommt.
D.h. meistens reicht es aus, einfach die Rechte des Ordners zu ermitteln.

Wenn du die Rechte ermitteln willst, z.B. mit Getnamedsecurityinfo, dann bekommst du eine Liste, die Discretionary Access Control List (DACL).
Das ist eine Liste mit Benutzer- und Gruppenaccounts, z.B. SYSTEM, Benuter, Administratoren usw. Da gibt es mehrere Typen, jedoch sind Allow und Deny die wichtigsten. Also ob der Zugriff für den Account erlaubt oder verweigert wird.
Jeder Access Control Eintrag (ACE) enthält zudem ein Access Right, das aussagt, welcher Zugriff gestattet ist. Die sind besonders aufgebaut. So können sie generische Rechte enthalten oder spezifische, z.B. GENERIC_ALL oder FILE_READ. Generische Rechte werden auf spezifische gemappt, z.B. GENERIC_WRITE wird zu FILE_GENERIC_WRITE, was wiederum nur ein Platzhalter für (STANDARD_RIGHTS_WRITE or FILE_WRITE_DATA or FILE_WRITE_ATTRIBUTES or FILE_WRITE_EA or FILE_APPEND_DATA or SYNCHRONIZE) ist (aber kein generischer, nur einfacher zu merken).

STANDARD_RIGHTS_WRITE ist eigentlich das Recht READ_CONTROL, welches das Auslesen der Rechte dem Account ermöglicht. WRITE_DAC wäre für das Schreiben der Rechte.

Weiterhin erhält der Besitzer noch zusätzliche Rechte, die ihm immer WRITE_DAC ermöglichen, auch wenn er nach der DACL kein Zugriff hätte.

Delphi-Quellcode:

type
  TRight = rNone, rRead, rReadWrite;

function GetFileRight(Filename: string): TRight;
function GetFileRightGroupName(Filename: string): string;

Um nun die Rechte des aktuellen Prozesses an einer Datei zu erfahren (GetFileRight), muss man eine spezielle Zugriffsprüfung mit dem Pseudorecht MAXIMUM_ALLOWED durchführen. D.h. man muss die Funktion AccessCheck aufrufen, die dann zurückliefert, welche Rechte man besitzt. Es gibt auch noch GetEffectiveAccessRights, welche jedoch nicht für alle Fälle das korrekte Resultat liefert. Dies geht für jeden Benutzer, dessen Token man besitzt. Will man dies für eine beliebigen Account durchführen, muss man diesen anmelden, denn manche Accounts, besonders in Domains, können zusätzliche Gruppen zugewiesen bekommen. Mit der AuthZ API (ab XP) kann man dies jedoch auch für beliebige Accounts machen, jedoch ist dann das Ergebnis nicht immer 100% deckend mit einem eingeloggten Account.

Das Ermitteln der Gruppe mit GetFileRightGroupName ist, nach meiner Ansicht, nicht einfach zu machen. Dazu muss man die Schnittmenge der eigenen Gruppen (eigener Account eingeschlossen) mit denen der DACL ermitteln. Da Gruppen jedoch auch verschachtelt sein können, kann das kompliziert werden.


Mit JWSCL kommt man übrigens für das erste Problem schneller voran:
http://blog.delphi-jedi.net/2010/03/...lder-security/

[Assarbad]

Um die echten Rechte im Stringformat zu ermitteln, gibt es aber tatsächlich seit Windows 2000 eine Methode.

Siehe: ConvertSecurityDescriptorToStringSecurityDescripto r und ConvertStringSecurityDescriptorToSecurityDescripto r (<-- :shock: noch'n Bug bei den MSDN-Tags und den ersten hat noch nichtmal jemand angenommen, da sollte kein Leerzeichen vor'm letzten "r" sein)

Daß das Ermitteln nicht trivial ist, da kann ich mich nur anschließen. Um ehrlich zu sein, besteht, selbst wenn du es jetzt richtig hinbekämst aus den DACLs das effektive Recht zu ermitteln, noch immer die Gefahr, daß sich eben diese Regeln ändern, solltest du es selber basteln (home-made).

Es gäbe da noch NtAccessCheck und Freunde, aber die sind native APIs und schlecht bis garnicht dokumentiert. Aber die kommen am nächsten an das was du vorzuhaben scheinst. Glücklicherweise gibt es dafür auch die Win32-Funktion AccessCheck :zwinker:

Das könntest du zusammen mit der von Christian empfohlenen Bibliothek ziemlich einfach implementieren.

[p80286]

Erste Vorraussetzung für Dein Vorhaben, ist, daß Du überhaupt das Recht hast, die Rechte zu lesen.
Je nachdem, wer sich um die NTFS-Rechtevergabe kümmert, können so interessante Konstellationen auftreten wie: DateiX darf von Benutzer Y gelesen,geschrieben,gelöscht werden und von Benutzer Z nicht. Benutzer Y hat aber keine Rechte auf Verzeichnis U in dem sich Datei X ja befindet. Wenn jetzt nur der Benutzer A den Vollzugriff auf Verzeichnis U und die Datei X hatte, dieser aber das Unternehmen vor 2 Monaten verlassen hat, und die DataAdmin Gruppe dummer Weise nicht zugelassen wurde, dann hat man sich eine echte Leiche gebastelt.

Aber Spaß beiseite, wenn ich mich richtig erinnere könntest Du bei Lucky fündig werden, ich glaube das Stichwort hieß DumpACL.

Zitat:

Zitat von Dezipaitor (Beitrag 1061144)

In 90% der Fälle besitzen Dateien keine eigenen Rechte, sondern bekommen sie vom übergeordneten Ordner vererbt, der sie meistens auch wieder vererbt bekommt.
D.h. meistens reicht es aus, einfach die Rechte des Ordners zu ermitteln.

Das kommt sehr auf die Benutzer an. Solange die Datei neu erstellt wird oder kopiert wird, funktioniert das. Aber sobald ein "MOVE" genutzt wird, dann wandern die orignären Rechte auch mit, und wenn dann der "Besitzer" verschollen ist...
Ich habe übrigens schon Dateien gesehen, die ererbte Rechte besaßen, wo der Vererber diese Rechte nicht (mehr) hatte.
(irgendwo ergibt sich natürlich immer ein Adminhintertürchen)
Gruß
K-H

[Assarbad]

Zitat:

Zitat von p80286 (Beitrag 1061178)

Erste Vorraussetzung für Dein Vorhaben, ist, daß Du überhaupt das Recht hast, die Rechte zu lesen.

Genau deswegen geht hier ja auch Probieren über Studieren. Also echt entweder das Objekt per AccessCheck (oder im KM SeAccessCheck) auf Zugriffsmöglichkeiten testen oder öffnen und ggf. einen Fehler melden.

Zitat:

Zitat von p80286 (Beitrag 1061178)

Benutzer Y hat aber keine Rechte auf Verzeichnis U in dem sich Datei X ja befindet.

Das ist bei den Standardinstallationen Unsinn, siehe SeChangeNotifyPrivilege.

NB: man unterscheide keine Rechte und Zugriff verweigern!

Zitat:

Zitat von p80286 (Beitrag 1061178)

[...] dann hat man sich eine echte Leiche gebastelt.

Nicht wirklich. Es gibt ja noch Backup-Privilegien.

Aber ohnehin ist es am besten sowas nicht selber nachzuprogrammieren sondern sich auf das vom System vorgegebene zu verlassen. Da kann man zumindest erstmal annehmen, daß es konsistentes Verhalten produziert (auch wenn das in Wirklichkeit nicht immer der Fall sein mag).

[Luckie]

Vorsicht, beim Verschienben ist das so eine Sache mit dem Rechten: http://www.michael-puff.de/Artikel/Z...schieben.shtml

Und hier mein Artikel zum Thema mit dem genannten Demo: http://www.michael-puff.de/Artikel/DACL.shtml

[Dezipaitor]

Zitat:

Zitat von p80286 (Beitrag 1061178)

Ich habe übrigens schon Dateien gesehen, die ererbte Rechte besaßen, wo der Vererber diese Rechte nicht (mehr) hatte.

Du meinst, z.B. eine Datei besitzt einen DACL Eintrag, der im SecurityEditor als vererbt angezeigt wird, jedoch der garnicht im übergeordneten Ordner existiert?

[MaBuSE]

Ich danke allen für die Antworten.
Ich werde mich heute damit beschäftigen und mir eine entsprechende Funktion bauen.

Assarbad gab mir den richtigen Hinweis ;-) AccessCheck

Ich denke der von Dezipaitor überarbeitete Quelltext von Nico wird mir weiterhelfen.
-> http://www.delphipraxis.net/122461-z...zw-testen.html
( @ Luckie: Der Link in dem Beitrag (#2) zu Deiner Homepage ist "broken". Aus ...\Developer\... wurde ...\Programmierung\...)

Hier noch ein Hinweis in eigener Sache ;-)

Warum benötige ich sowas: http://www.delphipraxis.net/155968-r...chnisbaum.html

Vielleicht hat jemand von Euch eine Idee wie man es besser machen könnte.
Wäre schön, wenn Ihr den Betrag lesen würdet.

Vielen Dank.
MaBuSE

[p80286]

Zitat:

Zitat von Dezipaitor (Beitrag 1061251)

Zitat:

Zitat von p80286 (Beitrag 1061178)

Ich habe übrigens schon Dateien gesehen, die ererbte Rechte besaßen, wo der Vererber diese Rechte nicht (mehr) hatte.

Du meinst, z.B. eine Datei besitzt einen DACL Eintrag, der im SecurityEditor als vererbt angezeigt wird, jedoch der garnicht im übergeordneten Ordner existiert?

Genau so etwas!
und es funktioniert trotzdem

Gruß
K-H

[Dezipaitor]

Ja, da ist das inherited Flag gesetzt. Das kann man machen, aber Windows ermittelt den falschen Vorgänger. Zudem kann es passieren, dass der Editor die ACEs auseinandernimmt und mehrfach darstellt.