Zurgiffsrechte bestimmen bzw. testen

[LokutusvB]

Hallo Leute,

wenn man nach Zugriffsrechten für Ordner bzw. Verzeichnisse googelt, bekommt man fast nur ellenlange Funktionen als Ergebnis geliefert. TSearchRec, FindFirst und co. durchsucht ja nur Ordnerstrukturen ja nach dem, wie ich es definiere. Oder gibt es hier schon eine Möglichkeit, wie ich die Rechte mit Hilfe von FindNext/FindFirst auslesen kann?

Was ist denn die kürzeste und schnellste Möglichkeit zu testen, ob ein Nutzer Zugriff auf einen Ordner hat (Lese- und /oder Schreibzugriff ist dabei egal)?

Ist es schneller, wenn ich versuche, etwas in den Ordner zu kopieren und wieder zu löschen oder gibt es hierfür eine kleine schnelle Funktion?

[Luckie]

Du könntest die Zugriffsrechte auslesen: http://www.michael-puff.de/Programmi...ileAccess.html

Oder eben versuchen eine Datei dort zu erstellen und den fehlercode dann auswerten. Wobei das auslesen der Zugriffsrechte eleganter ist.

[LokutusvB]

Danke für den Link.
So etwas ähnliches habe ich auch schon bei meiner Suche in einem Beitrag gefunden, wo es darum ging, Zugriffsrechte zu ändern. Eventuell kann ich das ganze ja noch ein wenig kürzen.

[Luckie]

Zitat von LokutusvB:

Eventuell kann ich das ganze ja noch ein wenig kürzen.

Das glaube ich kaum. Oder warum denkst du, dass Nico dort unnötigen Code rein geschrieben haben sollte? Und warum willst du ihn überhaupt kürzer haben? Was macht das für einen Unterschied, ob du nun 10 oder 50 Zeilen Code kopierst und aufrufst?

[Dezipaitor]

So kürzen?

http://blog.delphi-jedi.net/2007/10/21/why-jwscl/

Delphi-Quellcode:

function CheckAccessToFile(
  DesiredAccess: DWORD; const FileName: WideString): Boolean;
var FileObject : TJwSecureFileObject;
begin
  FileObject := TJwSecureFileObject.Create(FileName);
  try
    result := FileObject.AccessCheck(DesiredAccess);
  finally
    FileObject.Free;
  end;
end;

Das Erstellen einer Datei hat Unterschiede zum Auslesen der Zugriffsrechte:
1. Das Erstellen der Datei kann eine Überwachungslog (Audit) generieren. AccessCheck selbst macht das nicht. Es gibt extra AccessCheck Funktionen dafür.
2. Eine lokale Überprüfen der Zugriffsrechte auf einem entfernten System kann ein unterschiedliches Ergebnis ergeben, weil der Zugriff nur auf dem entfernten Rechner geschieht.

[Dezipaitor]

@Luckie: Kennst du Gründe warum ImpersonateSelf verwendet wurde, abseits meinem Grund, dass der Code threadsicher(er) ist?

[LokutusvB]

An Luckie:
Die Idee des Kürzens hatte ich, bevor ich den Quelltext genauer gelesen hatte. Es hätte ja gut sein können, das zusätzliche Informationen ausgelesen werde, die ich nicht benötige. Denn was bei meinem Programm zählt, ist die Zeit, da das ganze über das Netzwerk bzw. Internet läuft und so schon genug gebremst wird.

An Dezipaitor:
Ein sehr interessanter Link. das werde ich zumindest noch ausprobieren. CheckAccessToFile funktioniert so weit sehr gut , ohne einen spürbaren zusätzlichen Zeitfaktor beim Durchsuchen der Laufwerke und Ordner.

Danke für die Hilfe

[Dezipaitor]

Der obige OOP Code wird durch ständiges Erstellen und Zerstören von Objekten und einigen internen Überprüfungen (zur Sicherheit), sowie der aufruf von virtuellen Methoden (ist langsamer) natürlich langsamer ausgeführt als der reine WinAPI Code. JWSCL enthält aber auch Klassenmethoden, die es erlauben schnell die Sicherheitsdaten einer Datei zu lesen und mit AccessCheck (auch eine Methode) zu überprüfen. Da wird dann eben kein Objekt für jede Datei erstellt. Einige interne Sachen sind dann doch noch dabei. Die Klasse ist TJwSecureGeneralObject

[Luckie]

Zitat von Dezipaitor:

@Luckie: Kennst du Gründe warum ImpersonateSelf verwendet wurde, abseits meinem Grund, dass der Code threadsicher(er) ist?

Da müsstest du dich mal an Nico persönlich wenden. Der Code ist von ihm (Steht ja auch drunter).

[nicodex]

Zitat von Dezipaitor:

Kennst du Gründe warum ImpersonateSelf verwendet wurde, [...]

Es handelt sich in erster Linie um eine Vereinfachung (damit man nur noch OpenThreadToken braucht), um an das Token zu gelangen (sonst müsste man erstmal prüfen ob der Thread ein eigenes Token hat und alternativ das Token des Prozesses verwenden.

Wenn ich mich recht erinnere, dann handelt es sich um die (Re-)Implementierung einer API, die nicht in allen Versionen von Windows NT zur Verfügung steht...