Wer hat welche Berechtigungen in einem Verzeichnis

[Luckie]

Ich wollte ermitteln welcher Benutzer Schreib- und Leserechte in einem angegebenen Verzeichnis auf NT ff. Systemen hat. Sprich, ich gebe ein Verzeichnis an und bekomme zurück, wer lesend und wer schreibend darauf zugreifen kann.

Ich habe hier schon nach ACL gesucht, nur weiß ichnicht so recht, ob da was passendes bei ist, weil ich auch noch gra nicht weiß, wie ich das anpacken soll. Brauche ich da SID's, XYZID's oder was auch immer und wie würde das Vorgehen aussehen.

Edit1: Im SwissDelphiCenter habe ich auchn ichts brauchbares gefunden.
Edit2: Ziel ist es ein Programm zu schreiben, um sein System auf Lücken zu untersuchen, was die Vergabe von Rechten angeht. Eventuell das ganze auch andersrum, dass man der Benutzer angibt und eine Liste bekommt3 aufwelche Verzeichnisse er wie zugreifen kann.

[Sharky]

Hai Luckie,

ich bin mir nicht ganz sicher ob Dir das hilft, aber suche mal im PSDK nach FSCTL_SECURITY_ID_CHECK. Eventuell hilft dir das weiter.

[Luckie]

Nein, es muss irgendwas mit GetSecurityInfo sein. damit bekomme ich wohl eien DACL für das Objekt (Datei). Nur wie geht es dann weiter? Besser ist für mich wohl noch GetFileSecurity, da es mir ja nur um Dateien geht.

[Luckie]

Auf SysInternals habe ich genau das Programm gefunden, was das macht, was ich will, sogar mit Source. Nur leider steige ich bei dem C/C++ Gewusel einfach nicht durch. ich weiß noch nicht mal wo was anfängt bzw. in welcher Reihenfolge ich mir welche Infos holen muss um an die Berechtigungen dranzukommen.

Ich hänge es mal an.

[Luckie]

So, in einem WinAPI Forum wurde mir jetzt etwas weitergeholfen: http://www.c-plusplus.de/forum/viewt...=469825#469825

Ich versuche das gerade in Code umzusetzten:

Delphi-Quellcode:

uses
  AclAPI;


procedure TForm1.Button1Click(Sender: TObject);
var
  psd: PSECURITY_DESCRIPTOR;
  dwLen: DWORD;
  psdc: SECURITY_DESCRIPTOR_CONTROL;
  dwDummy: DWORD;
  DaclPresent, DaclDefaulted: LongBool;
  dacl: PACL;
  aclinfo: PAclInformation;
begin
  dwLen := 0;
  psd := nil;
  GetFileSecurity('c:\boot.ini', DACL_SECURITY_INFORMATION, psd, 0, dwLen);
  psd := AllocMem(dwLen);
  try
    if GetFileSecurity('c:\boot.ini', DACL_SECURITY_INFORMATION, psd, dwLen,
      dwLen) then
    begin
      GetMem(dacl, sizeof(PACL));
      try
        if GetSecurityDescriptorDacl(psd, DaclPresent, @dacl, DaclDefaulted) then
        begin
          if GetAclInformation(PAdacl, ) then
          begin
          end;
        end;
      finally
        Freemem(dacl, sizeof(PACL));
      end;
    end;
  finally
    FreeMem(psd, dwLen);
  end;
end;

Aber es will nicht so recht. PAclInformation kennt er nicht und hier:

Delphi-Quellcode:

if GetAclInformation(dacl, ) then

sagt er mir jetzt schon:

Zitat:

[Fehler] Unit1.pas(54): Inkompatible Typen: '_ACL' und 'PACL'

Ich bräuchte da mal eure Hilfe. :cry:

[NicoDE]

Zitat:

Zitat von Luckie

PAclInformation kennt er nicht

Versuche es mit den Win32API-Paket von Marcel van Brakel (http://www.delphi-jedi.org/APILIBRARY / http://members.chello.nl/m.vanbrakel2/).

Zitat:

Zitat von Luckie

Zitat:

[Fehler] Unit1.pas(54): Inkompatible Typen: '_ACL' und 'PACL'

Die mir bekannten AclAPI/AccCtrl.pas von Borland sind - meiner bescheidenen Meinung nach - unvollständig bis unbrauchbar (je nach Delphi-Version).

[The-X]

ist der Datentyp PACL ein Pointer auf ein Record?
Zwar ne dumme Frage, ist mir aber auch schon des öfteren passiert ;)

[Luckie]

Hier fängt es im MSDN an http://msdn.microsoft.com/library/de...lesecurity.asp und der Link aus dem c++-Forum beschreibt, wie man wohl vorgehen müsste.

[Markus K.]

Hi Luckie,
den ersten Parameter bei GetAclInformation musst du glaub ich so schreiben:

Delphi-Quellcode:

GetAclInformation(dacl^,)

Dann müsste die Fehlermeldung eigentlich weg sein :gruebel: weiß es aber nicht genau.

Tschüß Markus

[The-X]

Genau das meinte ich ja mit dem "Pointer auf einen Record"...
und aus der MSDN seite wurd ich (leider) net schlauer :roll:

[Luckie]

Nein das war es leider auch nicht. Und genau das ist auch mein Problem, aus dem MSDN werde ich auch nicht so recht schlau. :gruebel:

[Sharky]

Zitat:

Zitat von Luckie

Nein das war es leider auch nicht. Und genau das ist auch mein Problem, aus dem MSDN werde ich auch nicht so recht schlau. :gruebel:

Hai Luckie,

ich wollte diesen Thread noch einmal herausfischen und fragen ob Du oder jemand anderes denn eien Lösung gefunden hat?
Ich versuche das nämlich auch zur Zeit und finde keinen Weg.

[NicoDE]

Zitat:

Zitat von Sharky

Ich versuche das nämlich auch zur Zeit und finde keinen Weg.

Welche WinAPI-Units verwendest Du?
(ich habe es anno dazumal nur mit eigenen Übersetzungen zum Laufen bekommen)

[Olli]

Na wie ist denn GetAclInformation() bei euch in Delphisyntax deklariert, Jungs?

[Catbytes]

Zitat:

Zitat von Luckie

Ich wollte ermitteln welcher Benutzer Schreib- und Leserechte in einem angegebenen Verzeichnis auf NT ff. Systemen hat.

Welche Rechte meinst Du eigentlich genau?

Die Rechte bei Freigabe/Berechtigungen oder die bei den Sicherheitseinstellungen?

Zitat:

Zitat von Luckie

Delphi-Quellcode:

GetFileSecurity('c:\boot.ini', DACL_SECURITY_INFORMATION, psd, 0, dwLen);

Denk dran, daß nicht alle Benutzer automatisch C: als Systempartition besitzen.

[NicoDE]

Zitat:

Zitat von Catbytes

Denk dran, daß nicht alle Benutzer automatisch C: als Systempartition besitzen.

off-topic: Tcha, das sag mal den Tools von Microsoft (bootcfg und msconfig), denn dort ist es hart codiert :) Einzig das Systemsteuerungs-Applet 'versucht' - auf extrem aufwendigem, kryptischem und natürlich undokumentiertem Wege - die Systempartition zu bestimmen (dies ist mit 100%-er Sicherheit nicht möglich).

[Catbytes]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von Catbytes

Denk dran, daß nicht alle Benutzer automatisch C: als Systempartition besitzen.

off-topic: Tcha, das sag mal den Tools von Microsoft (bootcfg und msconfig), denn dort ist es hart codiert :) Einzig das Systemsteuerungs-Applet 'versucht' - auf extrem aufwendigem, kryptischem und natürlich undokumentiertem Wege - die Systempartition zu bestimmen (dies ist mit 100%-er Sicherheit nicht möglich).

:mrgreen: Wenn andere es falsch vormachen, muß man es ja nicht selbst machen.

Ich habe mich nie mit Systempartitionen ärgern müssen, weiß deshalb nicht, was da Voraussetzung ist. Im einfachsten Falle würde ich alle verfügbaren Laufwerke durchgehen und die boot.ini suchen (wenn das eine Voraussetzung wäre).

[Luckie]

@Catbytes: Diese Datei habe ichnur genommen, weil der Pfad so schön kurz war bei mir.

@Sharky: Nein, ich bin leider nicht weitergekommen.

[Sharky]

Zitat:

Zitat von NicoDE

... Welche WinAPI-Units verwendest Du?

Hai NicoDE,

ich abe mal die übersetzungen von den Jedis aus den weiten des Netzes gezogen. Mangels einer Dokumentation bringt mir das natürlic nicht so viel :stupid:

Und da ich selber überhaupt kein Crack bei dem ganzen "API-Kram" bin stecke ich schon von anfang an fest.

[NicoDE]

Was ist denn das eigentliche Ziel?

Ich frage deshalb, weil es einfacher ist, den Standard-Sicherheitsdialog (AclEdit) von Windows zum Laufen zu bekommen, als die Sicherheitsbeschreibungen selbst auswerten zu wollen...

[Sharky]

Zitat:

Zitat von NicoDE

Was ist denn das eigentliche Ziel?

Hai Nico,

der Hintergrund ist der:
In meinem Programm (zum Beispiel meine Buchverwaltung) möchte ich dem Anwender die Möglichkeit geben zu bestimmen wo die Datenbankdatei gespeichert werden soll (Verzeichniss der EXE, AppDir des Users, oder in einem frei wählbaren Verzeichniss).
Jetzt möchte ich natürlich gerne prüfen ob der Anwender überhaupt die Berechtigung hat in dem von ihm gewählten Verzeichniss eine Datei zu erstellen. Die könnte ich sicher auch mit try - except machen. Aber ich möchte eigentlich lieber einen Fehler verhindern als "nur auf ihn zu reagieren".

[Luckie]

Zitat:

Zitat von Sharky

möchte ich dem Anwender die Möglichkeit geben zu bestimmen wo die Datenbankdatei gespeichert werden soll (Verzeichniss der EXE, AppDir des Users, oder in einem frei wählbaren Verzeichniss).

Dir ust aber klarr dass bei meherern benutzern sie sich die datenbankdatei gegenseitig überschreiben, wenn sie beide im gleichen Verzeichnis ablegen?

[Sharky]

Zitat:

Zitat von Luckie

... Dir ust aber klarr dass bei meherern benutzern sie sich die datenbankdatei gegenseitig überschreiben, wenn sie beide im gleichen Verzeichnis ablegen?

Naja, ich glaube schon das ich vor dem erzeugen einer neuen Datenbankdatei prüfe ob diese in dem gewählten Verzeichniss schon vorhanden ist ;-)
Es soll, wenn mehrer Benutzer das Programm benutzen ja nur eine DB-Datei benutzt werden.

[Olli]

Zitat:

Zitat von Olli

Na wie ist denn GetAclInformation() bei euch in Delphisyntax deklariert, Jungs?

War eigentlich auch nur als Scherzfrage gedacht, sorry :roll:

[Sharky]

Zitat:

Zitat von Olli

...War eigentlich auch nur als Scherzfrage gedacht, sorry :roll:

:?: Verwirre doch keine kleinen Haifischlein die sich da überhaupt nicht auskennen.

[NicoDE]

Zitat:

Zitat von Sharky

der Hintergrund ist der:

[snip]

Versuch's damit (funktioniert auch mit Verzeichnissen)

Delphi-Quellcode:

(** )
// stuff Delphi might not know...
const
  FILE_READ_DATA            = $0001;  // file & pipe
  FILE_LIST_DIRECTORY       = $0001;  // directory
  FILE_WRITE_DATA           = $0002;  // file & pipe
  FILE_ADD_FILE             = $0002;  // directory
  FILE_APPEND_DATA          = $0004;  // file
  FILE_ADD_SUBDIRECTORY     = $0004;  // directory
  FILE_CREATE_PIPE_INSTANCE = $0004;  // named pipe
  FILE_READ_EA              = $0008;  // file & directory
  FILE_WRITE_EA             = $0010;  // file & directory
  FILE_EXECUTE              = $0020;  // file
  FILE_TRAVERSE             = $0020;  // directory
  FILE_DELETE_CHILD         = $0040;  // directory
  FILE_READ_ATTRIBUTES      = $0080;  // all
  FILE_WRITE_ATTRIBUTES     = $0100;  // all
  FILE_ALL_ACCESS      = STANDARD_RIGHTS_REQUIRED or SYNCHRONIZE or $1FF;
  FILE_GENERIC_READ    = STANDARD_RIGHTS_READ or
                         FILE_READ_DATA or
                         FILE_READ_ATTRIBUTES or
                         FILE_READ_EA or
                         SYNCHRONIZE;
  FILE_GENERIC_WRITE   = STANDARD_RIGHTS_WRITE or
                         FILE_WRITE_DATA or
                         FILE_WRITE_ATTRIBUTES or
                         FILE_WRITE_EA or
                         FILE_APPEND_DATA or
                         SYNCHRONIZE;
  FILE_GENERIC_EXECUTE = STANDARD_RIGHTS_EXECUTE or
                         FILE_READ_ATTRIBUTES or
                         FILE_EXECUTE or
                         SYNCHRONIZE;
(**)

function CheckAccessToFile(DesiredAccess: DWORD; const FileName: WideString): Boolean;
const
  GenericFileMapping: TGenericMapping = (
    GenericRead   : FILE_GENERIC_READ;
    GenericWrite  : FILE_GENERIC_WRITE;
    GenericExecute: FILE_GENERIC_EXECUTE;
    GenericAll    : FILE_ALL_ACCESS
  );
var
  LastError: DWORD;
  LengthNeeded: DWORD;
  SecurityDescriptor: PSecurityDescriptor;
  ClientToken: THandle;
  AccessMask: DWORD;
  PrivilegeSet: TPrivilegeSet;
  PrivilegeSetLength: DWORD;
  GrantedAccess: DWORD;
  AccessStatus: BOOL;
begin
  Result := False;
  LastError := GetLastError;
  if not GetFileSecurityW(PWideChar(FileName), OWNER_SECURITY_INFORMATION or
    GROUP_SECURITY_INFORMATION or DACL_SECURITY_INFORMATION, nil, 0,
    LengthNeeded) and (GetLastError <> ERROR_INSUFFICIENT_BUFFER) then
    Exit;
  SetLastError(LastError);
  Inc(LengthNeeded, $1000);
  SecurityDescriptor := PSecurityDescriptor(LocalAlloc(LPTR, LengthNeeded));
  if not Assigned(SecurityDescriptor) then
    Exit;
  try
    if not GetFileSecurityW(PWideChar(FileName), OWNER_SECURITY_INFORMATION or
      GROUP_SECURITY_INFORMATION or DACL_SECURITY_INFORMATION,
      SecurityDescriptor, LengthNeeded, LengthNeeded) then
      Exit;
    if not ImpersonateSelf(SecurityImpersonation) then
      Exit;
    try
      if not OpenThreadToken(GetCurrentThread, TOKEN_QUERY or
        TOKEN_IMPERSONATE or TOKEN_DUPLICATE, False, ClientToken) then
        Exit;
      try
        AccessMask := DesiredAccess;
        MapGenericMask(AccessMask, GenericFileMapping);
        PrivilegeSetLength := SizeOf(TPrivilegeSet);
        if AccessCheck(SecurityDescriptor, ClientToken, AccessMask,
          GenericFileMapping, PrivilegeSet, PrivilegeSetLength, GrantedAccess,
          AccessStatus) then
          Result := AccessStatus;
      finally
        CloseHandle(ClientToken);
      end;
    finally
      RevertToSelf;
    end;
  finally
    LocalFree(HLOCAL(SecurityDescriptor));
  end;
end;

////////////////////////////////////////////////////////////////////////////////
// Test

procedure TForm1.Button1Click(Sender: TObject);
begin
  if OpenDialog1.Execute then
    ShowMessage(BoolToStr(
      CheckAccessToFile(GENERIC_WRITE,  // check for generic write access
      OpenDialog1.FileName), True) + ': ' + SysErrorMessage(GetLastError));
end;

edit: nicht mein Tag heute *g*

[NicoDE]

Zitat:

Zitat von Luckie

Ich wollte ermitteln welcher Benutzer Schreib- und Leserechte in einem angegebenen Verzeichnis auf NT ff. Systemen hat. Sprich, ich gebe ein Verzeichnis an und bekomme zurück, wer lesend und wer schreibend darauf zugreifen kann.

Colin Wilson - Delphi 6/7 - NT Low Level Utilities - TFileObject

[Sharky]

Zitat:

Zitat von NicoDE

...Versuch's damit (funktioniert auch mit Verzeichnissen)

Hai Nico,
ersteinmal DANKE für die schöne Funktion :-D
Lokal funktioniert sie auch. Allerdings habe ich da noch eine Frage:
Wenn die Funktion TRUE zurückgibt steht in GetLastError immer:

Zitat:

Der an einen Systemaufruf übergebene Datenbereich ist zu klein

Kannst Du mir sagen warum das so ist?

Ach ja: Gibt es eine ähnliche Möglichkeit auch für Netzwerklaufwerke?

[NicoDE]

Zitat:

Zitat von Sharky

Wenn die Funktion TRUE zurückgibt steht in GetLastError immer:

Zitat:

Der an einen Systemaufruf übergebene Datenbereich ist zu klein

Kannst Du mir sagen warum das so ist?

a) Bitte nachsehen ob du aktuelle Version hast (hatte heute morgen deswegen noch den Code ergänzt um den 'LastError' zu sichern).

Der Fehlercode ist nur bei Rückgabe von False interessant (in dem Beispiel so einfach gehalten weil ich keine Lust hatte dort noch ein if einzubauen *g*).
Ansonsten wird der 'LastError' im Erfolgsfalle normalerweise nicht geändert (deswegen wird er oben gesichert, da der erste Aufruf von GetFileSecurity den von dir genannten Fehlercode generieren muss)...

Zitat:

Zitat von Sharky

Ach ja: Gibt es eine ähnliche Möglichkeit auch für Netzwerklaufwerke?

Öhm, "\\foo\bar.42" funktioniert bei mir problemlos...

[Sharky]

Zitat:

Zitat von NicoDE

... Bitte nachsehen ob du aktuelle Version hast

Nö, hatte natürlich die Version von gestern :-P

Zitat:

Der Fehlercode ist nur bei Rückgabe von False interessant

Jo, es hatte mich nur interessiert warum diese Meldung gekommen war. Jetzt wo Du es sagst habe ich es selber gesehen.

Zitat:

Öhm, "\\foo\bar.42" funktioniert bei mir problemlos...

*g* Bei mir jetzt auch. Ich hatte da einen kleinen "Denk"fehler.

:hello: Also, danke nochmals!

[Sharky]

Hai Nico,

eine Frage habe ich noch ;-)

Ich habe in deiner Funktion des Result-Type auf Integer geändert und im Code dann geschrieben:

Delphi-Quellcode:

begin
  Result := -1;
.
.
  if AccessCheck(SecurityDescriptor, ClientToken, AccessMask,
     GenericFileMapping, PrivilegeSet, PrivilegeSetLength, GrantedAccess,
     AccessStatus) then
  begin
    // Result := AccessStatus;
    Result := GetLastError
  end;
.
.

Dadurch kann ich etwas "leichter" die Fehler auflösen:

Delphi-Quellcode:

procedure TForm1.btn_Button1Click(Sender: TObject);
var
  pfad: string;
begin
  pfad := edt_Edit1.Text;
  case CheckAccessToFile(GENERIC_WRITE, pfad) of
    -1:
    begin
      ShowMessage('Fehler beim Ausführen')
    end;
    NO_ERROR:
    begin
      ShowMessage('Alles Okay')
    end;
    ERROR_ACCESS_DENIED:
    begin
      ShowMessage('Zugriff verweigert')
    end;
    ERROR_LOGON_FAILURE:
    begin
      ShowMessage('Fehler bei der Anmeldung')
    end;
  end;
end;

Ist das Okay so oder ist da noch eine Falle in meinem Code?

[NicoDE]

Jupp, der Benutzer könnte das Verzeichnis zwar auswähen aber nicht die Sicherheitsbeschreibungen lesen können (wenn ich noch länger darüber nachdenke fällt mir bestimmt noch mehr ein *g*).
Ich würde es so lassen (Boolean).
Was spricht gegen:

Delphi-Quellcode:

if not CheckAccessToFile(...) then
  case GetLastError of
    ERROR_TOO_STUPID,
    ERROR_GO_WINDOWS,
    ERROR_DROP_DEAD:
  //...
  end;

ps: wo ist dein else ?-)
pps: dein Code kann ohnehin nicht sicher funktionieren (zumindest nicht so wie du es erwartest), da im Erfolgsfalle 'LastError' nicht gesetzt wird...

[Sharky]

Zitat:

Zitat von NicoDE

...
Ich würde es so lassen (Boolean).
Was spricht gegen:

Jup, hast recht.

Zitat:

ps: wo ist dein else

Else war ausverkauft ;-)

Zitat:

.. da im Erfolgsfalle 'LastError' nicht gesetzt wird...

Ups, da bei meinen Testläufen LastError im Erfolgsfall immer 0 war hatt ich mich darauf verlassen.

Aber wie schon gesagt: Ich mache so wie von Dir vorgeschlagen.

[Brainshock]

Hi,

nochmal zum Test von Netzlaufwerken. Ich habe eine Freigabe unter XP (Zugriff: \\rechner\freigabe\ Berechtigungen: Jeder->Lesen) gemacht und die mit CheckAccessToFile() und FILE_GENERIC_WRITE getestet. Jetzt gibt mir die Funktion aber True zurück, wie kann das sein? :?

Gruß

[NicoDE]

Zitat:

Zitat von Brainshock

Ich habe eine Freigabe unter XP (Zugriff: \\rechner\freigabe\ Berechtigungen: Jeder->Lesen) gemacht und die mit CheckAccessToFile() und FILE_GENERIC_WRITE getestet. Jetzt gibt mir die Funktion aber True zurück, wie kann das sein?

Testest Du die Freigabe auf dem selben Rechner? Welche Parameter werden übergeben?

[Brainshock]

1. Freigabe ist auf einem Nachbarrechner (\\eg01\testfreigabe) mit Windows XP.
2. Der Aufruf ist wie gehabt:

Delphi-Quellcode:

 
ShowMessage(BoolToStr(CheckAccessToFile(FILE_GENERIC_WRITE, '\\eg01\testfreigabe'), True) + ': ' + SysErrorMessage(GetLastError));

[Brainshock]

Wenn ich die Funktion mit einer Windows 2000 Freigabe teste (Berechtigung: Nur lesen) fliegt er schon bei GetFileSecurityW() mit "Zugriff verweigert" raus, was wahrscheinlich auch richtig so ist.

Nur warum liefert mir Windows XP falsche Werte ?

[NicoDE]

Wie ist der Rückgabewert wenn Du GENERIC_WRITE verwendest?
(gibt es sonst irgendwelchen Besonderheiten? Domäne vs Arbeitsgruppe, admintrativer Account, usw)

[Luckie]

Was für ein XP? Home oder Professinal?

[Brainshock]

@NicoDE:

Zitat:

Wie ist der Rückgabewert wenn Du GENERIC_WRITE verwendest?

Die Rückgabe ist "True: Der Vorgang wurde erfolgreich beendet".
Werte ich jetzt noch die Rückgabe GrantedAccess von AccessCheck() in CheckAccessToFile() aus, bekomme ich für GENERIC_WRITE mein False. Das sollte es doch sein oder ? :gruebel:

Zitat:

(gibt es sonst irgendwelchen Besonderheiten? Domäne vs Arbeitsgruppe, admintrativer Account, usw)

- Arbeitsgruppe
- Admin-Account (Administrator)

@Luckie

Zitat:

Was für ein XP? Home oder Professinal?

Ich benutze Windows XP Pro.