Hat Benutzer Schreibrechte (lokal/LAN)?

[MCXSC]

Hallo,

ich habe eine kleine Frage:

Gibt es eine einfache Möglichkeit, herauszufinden, ob der aktuelle Windows-Benutzer Schreibrechte auf eine ausgewählte Datei hat? Sowohl lokal, als auch im Netzwerk?

Danke im vorraus,
MCXSC

[Bernhard Geyer]

Öffne sie mit TFileStream und Anforderung Schreizugriff und werte im Fehlerfall mit GetLastResult den Fehlergrund aus.

[Dezipaitor]

Zitat:

Zitat von Bernhard Geyer

Schreizugriff

*g* :hello:
Das ist zum Schreien komisch :D

[Helmi]

Hallo,

ich stehe ebenfalls vor dem gleichen Problem, dass ich die Schreibrechte lokal als auch im LAN feststellen, bzw. prüfen muss.

Ist das das einzigste, simpelste Lösung mit dem TFileStream oder gibt es noch was besseres?

[Sir Rufo]

Kuckst du hier, da sind auch Fuktionen um die Berechtigung für ein Verzeichnis auszulesen

[Helmi]

Zitat:

Zitat von Sir Rufo (Beitrag 1056237)

Kuckst du hier, da sind auch Fuktionen um die Berechtigung für ein Verzeichnis auszulesen

Sir Rufo, Sir! :mrgreen:

Ich denke du meinst die Procedure "CheckAccessToFile".
Die hab ich hier schon gefunden. Nur scheint diese nur für lokale Schreibrechte zu gelten/funktionieren...

[Luckie]

Man lese, was Nico dazu geschrieben hat:

Zitat:

Dazu sollte man noch anmerken, dass damit die 'lokalen' Zugriffsrechte überprüft werden.
Wenn man eine Datei im Netzwerk überprüfen möchte, muss zusätzlich die Sicherheitsbeschreibung der Freigabe beachtet werden.

[Helmi]

Zitat:

Zitat von Luckie (Beitrag 1056243)

Man lese, was Nico dazu geschrieben hat:

Zitat:

Dazu sollte man noch anmerken, dass damit die 'lokalen' Zugriffsrechte überprüft werden.
Wenn man eine Datei im Netzwerk überprüfen möchte, muss zusätzlich die Sicherheitsbeschreibung der Freigabe beachtet werden.

Ganz meine Rede!
Deswegen ja auch die Frage nach einer Funktion zur Schreibrecht-Prüfung für Lokal UND lan

[Dezipaitor]

Und dann wäre da noch die Sache mit >=Vista und SecurityLevel, das im Code auch nicht geprüft wird. Letztendlich muss man die Datei zum Schreiben öffnen, um kurz Gewissheit zu haben.

[p80286]

Ich hab den Beispielcode von Matze mal auf unser Netzwerk losgelassen, und er funktioniert so wie er soll. (XP)

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von Dezipaitor (Beitrag 1056284)

Und dann wäre da noch die Sache mit >=Vista und SecurityLevel, das im Code auch nicht geprüft wird. Letztendlich muss man die Datei zum Schreiben öffnen, um kurz Gewissheit zu haben.

Wenn du die Auswirkung der UAC meinst, dann kann ich das aber nicht nachvollziehen. (s. Anhang)

[Dezipaitor]

Zitat:

Zitat von p80286 (Beitrag 1056285)

Ich hab den Beispielcode von Matze mal auf unser Netzwerk losgelassen, und er funktioniert so wie er soll.

Mal eben etwas ausprobieren reicht nicht aus, den Code als funktionsfähig zu deklarieren. Ich kenne die Grundlagen zu dem Thema und kann daher die Probleme am Code sehen. Die Fehler durch Tests zu finden ist, wie die Nadel im Heuhaufen. Dass der Code nicht unbedingt im Netzwerk funktionieren muss, findet man schließlich auch nicht so leicht durch Tests heraus. Die Labelsecurity in Vista kommt halt jetzt noch dazu. Die Funktion wird TRUE zurückliefern, wenn ein Objekt eine höheres Integritylabel besitzt als der Nutzer.

[Helmi]

Hallo,

wärs dann nicht einfacher/besser die dreckige Version zu verwenden, indem man versucht eine Datei zu erzeugen, schlägt dies fehl dann weiss man (vermutet man) dass man keine Schreibrechte hat.

[shmia]

Folgender Code prüft, ob eine bestehende Datei beschreibbar ist:

Delphi-Quellcode:

function FileIsWriteable(const filename:string):Boolean;
var
   hnd: THandle;
begin
   hnd := CreateFile(PChar(filename), GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
   Result := hnd <> INVALID_HANDLE_VALUE;
   if Result then
      CloseHandle(hnd);
end;

Um zu prüfen, ob man in einem Verzeichnis eine neue Datei erzeugen kann,
also ob man Schreibrechte in einem Verzeichnis hat,
muss man einfach versuchen eine Datei zu schreiben.
Man sollte eine Dateiendung verwenden, die sonst nicht benützt wird (.tmp, .$$$).
Wenn man Pech hat, kann man die temporäre Datei erzeugen, aber danach nicht mehr löschen.
Das kommt aber relativ selten vor.

[Dezipaitor]

Also eigentlich sollte man es so machen. CreateFile hat doch noch irgendwo so ein temporary Flag, so dass die Datei gelöscht wird, sobald alle Handles geschlossen sind (bin zu faul zum suchen :-D ). Ich würde dann auch alle Share Attribute rausmachen, so dass kein anderer Prozess zwischendrin die Datei öffnen kann. Soll ja nur getestet werden, ob das geht. Gab es nicht auch noch ein Flag für zufällige Namen? (faul :-D )
Wenn das so gemacht wird, dann gibt es auch kein Problem mit dem Löschen, außer die Verbindung reißt ab. Obwohl selbst dann die Datei vom Server automatisch gelöscht werden sollte.

Zitat:

Zitat von Sir Rufo (Beitrag 1056293)

Zitat:

Zitat von Dezipaitor (Beitrag 1056284)

Und dann wäre da noch die Sache mit >=Vista und SecurityLevel, das im Code auch nicht geprüft wird. Letztendlich muss man die Datei zum Schreiben öffnen, um kurz Gewissheit zu haben.

Wenn du die Auswirkung der UAC meinst, dann kann ich das aber nicht nachvollziehen. (s. Anhang)

Ich kann ehrlich gesagt nichts mit den Bildern anfangen. Such mal nach Integrity Level bzw Label im Inet oder hier. Diese Label kann man nur mit icacls anzeigen. Mit UAC haben die aber nicht wirklich etwas zu tun. Das ist nur ein zusätzliches Konzept zur Zugriffsbestimmung zur DACL.

[Bernerbaer]

Zitat:

Zitat von Helmi (Beitrag 1056369)

Hallo,

wärs dann nicht einfacher/besser die dreckige Version zu verwenden, indem man versucht eine Datei zu erzeugen, schlägt dies fehl dann weiss man (vermutet man) dass man keine Schreibrechte hat.

Für mich ist das nicht "dreckig" sondern die _einzige_ praktikable Lösung. Man ist dann auch nicht auf Vermutungen angewiesen, sondern erhält Vom OS auch einen konkreten Grund weshalb es nicht funktioniert hat.