_FileWriteLog kann keine Logfiles schreiben ohne Datei zu öffnen

  • Hallo zusammen,

    ich bin neu hier im Forum und auch neu bei AutoIt und hoffe, ihr könnt mir weiterhelfen.

    Gegeben ist eine Serverfreigabe auf einem Windows Server 2008. In dieser Freigabe liegen div. Verzeichnisse, auf die die User zugreifen können, mal nur lesend, mal lesend und schreibend (z.B. Z:\Treiber\, Z:\Datenaustauch\ usw.)...
    Es gibt auch ein Verzeichnis für Logfiles, in dem je User Logfiles angelegt werden, z.B. von Loginscripten (Bsp.: Z:\Logfiles\AMustermann.log).
    Auf dieses Verzeichnis LOGFILES haben die User allerdings nur Schreibrechte (also nicht die NTFS-Berechtigung "Ordner auflisten/Daten lesen"), so dass sie das Verzeichnis nicht öffnen bzw. die darin befindlichen Dateien nicht anzeigen können. Hintergrund ist der Datenschutz (z.B. soll Herr Müller nicht am Logfile von Herrn Meier erkennen können, wann dieser sich ein- und ausloggt etc.)

    Bisher haben Batch-Skripte dort ihre Logfiles abgelegt - ohne Probleme. Nun möchte ich die Batch-Skripte durch Programme ersetzen, die ich mit AutoIt optimiere, womit ich zu meinem problem komme:

    Die Funktion _FileWriteLog kann ihr Logfile nicht schreiben, da sie es nicht finden/öffen kann (Rückgabewert 0 und @error-Wert 1), weil dem ausführenden User ja die Berechtigungen zum Anzeigen/Auflisten/Öffnen/... fehlen.

    Hat jemand eine Idee, das umzusetzen, ohne die Berechtigungen anzupassen? Ich bin für jeden Tipp dankbar :)

    Besten Dank und süße Grüße, die Schokolade <3

  • Du scheinst den 3. Parameter von _FileWriteLog zu benutzen (<> -1), dadurch wird das File gelesen.

    Code: File.au3
    If $iFlag <> -1 Then
    		$iOpenMode = $FO_OVERWRITE
    		$sMsg &= @CRLF & FileRead($sLogPath)
    	EndIf


    Also einfach den 3. Parameter weglassen, damit Defaultwert -1 benutzt wird.

    mfg autoBert

  • :Glaskugel: , da Quellcode,... fehlt
    Nun. Ohne Berechtigung wirst du das nicht hinbekommen. Sonst wären Berechtigungen ja unnütz.
    Was ginge: Ein Programm als System/Admin-prozess automatisch beim hochfahren starten lassen und dem System/Admin rechte zum lesen/schreiben des Verzeichnisses geben.
    Dafür musst du natürlich beim "installieren" als Administrator angemeldet sein.

  • Wenn er das macht kann aber jeder alle Logs lesen. Das einzige was man dazu braucht ist der komplette Netzwerkpfad zur Datei. Den Ordner nur vor Auflistung zu schützen schützt noch lange nicht die Dateien darin. Da die Logfiles mit Sicherheit nach einem fixen Schema benannt sind dürfte es nicht all zu schwer sein auf den Namen von fremden Logfiles zu schließen.

    Die vom TE angewendete Methode halte ich daher für problematisch, zumindestens in Verbindung mit deiner vorgeschlagenen Rechteanpassung.

    Ich würde daher wie auf deinem Screenshot zu sehen ist einen nicht personalisierten Systemuser für die Datenübertragung auf das Netzlaufwerk nutzen. Nur dieser Systemuser hat ausreichende Rechte um die Logfiles zu bearbeiten. Die eigentlichen User Scripte schreiben ihr Logfile nur auf die lokale Festplatte und diese werden dann von einem weiteren Script welches im Kontext des Systemusers ausgeführt wird letzlich auf das Netzlaufwerk kopiert (in Intervallen oder bei jeder Dateiänderung des lokalen Logfiles). Alternativ könnte man die Logfiles auch durch ein Script welches auf dem Dateiserver läuft regelmässig von den Clients abholen (Administrative C$ Freigabe auf dem Client Rechner).

    Letztere Variante hätte zumindestens den Vorteil, dass keine Accountdaten für den Systemuser auf dem Client gespeichert werden müssen. Wenn man die Aufgabenplannung nutzt um das Übertragungsscript zu starten dürfte das gespeicherte Passwort des Systemusers aber auch im ersteren Fall vor dem Anwender sicher sein.

    Weitere Alternative wäre es ganz auf Dateibasiertes Logging zu verzichten und Stattdessen die Logs "live" per TCP/UDP an einen evtl. bereits vorhandenen Logserver zu übertragen.
    Stichwort syslog --> https://de.wikipedia.org/wiki/Syslog
    Du findest hierfür evtl. sogar passende Client Implementierungen in Autoit.

  • Hallo Kanashius, danke für deine Antwort :)

    >>>da Quellcode fehlt
    Wozu Quellcode? _FileWriteLog mit dem Zielpfad, auf den die entspr. User nur Schreibrechte haben.

    >>>Sonst wären Berechtigungen ja unnütz.
    Gut erkannt - deshalb arbeite ich ja mit den Berechtigungen und habe sie so konfiguriert, dass der User eben nicht im Verz. lesen (Dateien anschauen etc.), sondern nur schreiben (loggen) kann. ;)

    Hallo _mk_, auch dir Danke für deine Antwort :=)
    Ich bin nciht mehr im Büro und probiere das Montag gleich mal aus. Aber wenn ich mich nicht irre, könnte ein findiger User mit diesen Berechtigungseinstellungen doch problemlos z.B. via Kommandozeile gezielt Logs öffnen (zwar nicht das Verzeichnis öffnen und Dateien auflisten, aber mit dieser Berechtigung die Dateien lesen)..??..

  • Hallo misterspeed, vielen Dank für deine Ausführungen.

    >>>Wenn er das macht kann aber jeder alle Logs lesen. Das einzige was man dazu braucht ist der komplette Netzwerkpfad zur Datei.
    Genau, wie ich eben schon in meiner Antwort geschrieben habe.

    >>>Da die Logfiles mit Sicherheit nach einem fixen Schema benannt sind dürfte es nicht all zu schwer sein auf den Namen von fremden Logfiles zu schließen.
    Richtig ;)

    Die Logfiles lokal zu hinterlegen habe ich auch schon überlegt, finde ich aber nicht gut (Rechner des Users aus = Logfile nicht zugänglich).
    Die Logfiles lokal "zwischenzuparken" und dann in das entspr. Verzeichnis zu schieben (mit einem separaten Useraccount) wäre eine Alternative, wenn auch sehr umständlich:
    Logfile auf C:\ schreiben -> Skript fertig -> Logfile-Inhalt an entspr. vorh. Logfile im Zielverz. anhängen -> Logfile auf C:\ löschen

    Gibt es vielleicht eine Möglichkeit, die Funktion _FileWriteLog innerhalb des Skripts mit einem anderen Benutzer aufzurufen?

    Ich verstehe nicht, warum die Batchskripte das problemlos gemacht haben, es aber nicht mit AutoIt realisierbar ist (ohne was an den Berechtigungen zu ändern)? :(

    Es muss ja nicht _FileWriteLog sein, gibt es vielleicht andere Funktionen, mit denen man Datum, Uhrzeit + indiv. Text in eine Datei schreiben kann, die man ausprobieren könnte?

    PS: Das mit dem Logserver scheint mir mit Kanonen auf Spatzen zu schießen.

  • Ich verstehe nicht, warum die Batchskripte das problemlos gemacht haben, es aber nicht mit AutoIt realisierbar ist (ohne was an den Berechtigungen zu ändern)?

    Ist kein AutoIt-Problem, beim Testen konnte ich in einem Verzeichnis in dem ich mir die Leserechte genommen hatte auch mit NotePad keine Dateien schreiben. Kannst du den in einem Verzeichnis auf das du nur Schreibrechte hast mit NotePad schreiben?

  • >>>Kannst du den in einem Verzeichnis auf das du nur Schreibrechte hast mit NotePad schreiben?
    Naja, wie soll das gehen? Wenn ich Notepad öffne und die Datei speichern will, muss ich ja in das Zielverzeichnis navigieren. Wenn ich als Dateiname den direkten Pfad angebe, meckert Notepad, dass der Pfad nicht verfügbar ist.
    Mit CMD und klappt es problemlos:

    Code
    ECHO test >>\\ZIELPFAD\OHNE_LESE_RECHTE\test.txt

    Zur Not müsste ich die Logs mittels @Comspec in Komb. mit @SW_HIDE schreiben aber das ist ja auch wieder von hinten durch die Brust ins Auge...

  • PS: Das mit dem Logserver scheint mir mit Kanonen auf Spatzen zu schießen.

    Das kommt natürlich auf eure Infrastruktur an. Aber in mittleren bis großen Unternehmen ist es üblich, dass bereits ein solcher zentraler Server vorhanden ist, welcher sämtliche Logfiles im Unternehmen entgegennimmt. Seien es Logs von diversem Hardware Equipment wie Switche, Firewalls, Accesspoints bis hin zu Serverlogs und evtl. sogar Clientlogs. Die dort angesammelten Logs können dann wunderbar "live" durch spezialisierte Software durchsucht und automatisch auf Ungregelmässigkeiten analysiert werden. Für eine 10 Mann Firma ist sowas aber natürlich etwas übertrieben.

    Was dein Batch Script anderst macht kann man dir hier nicht sagen. Du hast weder ein funktionierendes Beispiel Batch Script bereitgestellt noch Details dazu gepostet wie und in welchem Benutzer Kontext die Batch- und Autoit Scripte ausgeführt werden (Systemuser, Als Administrator, ohne/mit #requireadmin,...). Auch hast du keine Angaben zu den involvierten Betriebssytem- und Autoit Versionen gemacht. Evtl. ebenfalls relevant wären Angaben dazu ob die Benutzer lokale Administratoren sind, ob die Windows Benutzerkontensteuerung aktiv ist und welche lokale Antivirensoftware eingesetzt wird.

    Prinzipiell könntest du den Teil des Logversandes/-schreiben testweise als Batch / CMD Aufruf in deinem Autoit Script einbauen und schauen ob es dann wieder funktioniert.

  • Achja eine Idee hätte ich noch. Ändere die Datei-Berechtigungen im Ordner dahingehend, dass der "ERSTELLER-BESITZER" einer Datei zusätzlich Lese Rechte erhält. Dadurch dürften nur selbst erstelle Dateien lesbar sein.

    EDIT:

    Als Ergänzung könnte man auch das hier testen

    • Ordner listbar für alle Benutzer, aber keine Dateilese Rechte (Option: Nur dieser Ordner)
    • Dateien Erstellen für alle Benutzer (Option: Nur dieser Ordner)
    • Dateien nur für "ERSTELLER-BESITZER" lesend und schreibende Rechte (Nur Dateien)

    Ob das so den gewünschten Effekt hat müsste man testen, hab ich jetzt aber keine Lust dazu. Der Nachteil der Listrechte wäre aber, dass man prinzipiell eine Liste aller Benutzer einsehen kann und außerdem anhand der Datei Änderungsdaten evtl. Rückschlüsse auf die Anwesenheit und Ab- und Anmeldezeiten der Benutzer schließen kann. Was ja laut deiner Aussage verhindert werden muss.

    Einmal editiert, zuletzt von misterspeed (19. Februar 2016 um 20:04)

  • >>>dass der "ERSTELLER-BESITZER" einer Datei zusätzlich Lese Rechte erhält. Dadurch dürften nur selbst erstelle Dateien lesbar sein.
    Das ist ein interessanter Ansatz, dann könnten die User wenigstens keine Logs der anderen User sehen. Werde ich mal probieren.

    >>>Du hast weder ein funktionierendes Beispiel Batch Script bereitgestellt
    Wie das Batchfile exakt aufgebaut ist, ist meiner Ansicht nach ja auch irrelevant. Es erledigt div. Aufgaben (u.a. Kopieren diverser Vorlagen Dateien) und schreibt dann mittels echo das Logfile, z.B.

    Code
    echo %date% %time% Das ist passiert. >>\\Pfad\Verz\Logdatei.log

    >>>wie und in welchem Benutzer Kontext die Batch- und Autoit Scripte ausgeführt werden

    Die Skripte werden mittels Gruppenrichtlinie als Logon- und Logoff-Skripte im Sicherheitskontexst des jeweils angemeldeten Benutzers ausgeführt.

    >>>keine Angaben zu den involvierten Betriebssytem- und Autoit Versionen gemacht.
    Windows 7 Professional SP2, meist 64, vereinzelt 32 Bit Versionen. AutoIt Version ist v3.

    >>>Angaben dazu ob die Benutzer lokale Administratoren sind
    Einige User sind lokale Admins, andere nur Benutzer, war bisher bei Verwendung der Batchskripte aber irrelevant. Die Skripte sollen z.B. Netzlaufwerke verbinden, E-mail-Signaturen, Wordvorlagen etc. ins Userverzeichnis kopieren usw. Also keine Aktionen, die das lokale System ändern wie Installationen o.Ä.....

    >>>welche lokale Antivirensoftware eingesetzt wird.
    Die Antivirensoftware ist von Standort zu Standort verschieden - auch hier wüsste ich nicht, in wie fern das Einfluss auf die NTFS Rechte bzw. die Tatsache, dass AutoIt eine Datei zwingend erst lesen/öffnen muss anstatt einfach nur (wie CMD) anzuhängen, hat.


    Mal allgemein gefragt: Wie würdet ihr das denn lösen, wenn die Vorgaben wie folgt lauten?
    - Ein zentrales Verzeichnis für Logfiles
    - Ein Logfile je User (in das die verschiedenen Skripte dann ihren Skriptnamen und die durchgeführten Operationen + Datum und Uhrzeit reinschreiben)
    - Log-Verzeichnis soll für die User nicht sichtbar bzw. der Inhalt nicht einsehbar sein (Stichwort Datenschutz)

  • autoBert:
    Ich habe niemandem die Leserechte genommen, sondern lediglich Schreibrechte vergeben.. So sehen die Rechte der User auf das Logverz. aus:
    2016-02-19_20h04_04.jpg

    Die User können weder das Verz. noch die darin befindlichen Dateien öffnen/auflisten/ansehen, aber darin schreiben (zumindest CMD im Sicherheitskontext des Users).

    >>>du kannst aber auch für jeden Nutzer ein Verzeichnis anlegen auf dem nur er, das System und die Admistratoren alle nötigen Berechtigungen haben.
    Das ist keine Option, denn a) zu aufwendig und b) zu unübersichtlich. Es soll schon so sein, dass in einem Verzeichnis alle Logfiles liegen, sodass man z.B. nach Datum sortieren kann, welches zuletzt geändert wurde.

  • >>>du kannst aber auch für jeden Nutzer ein Verzeichnis anlegen auf dem nur er, das System und die Admistratoren alle nötigen Berechtigungen haben.
    Das ist keine Option, denn a) zu aufwendig und b) zu unübersichtlich. Es soll schon so sein, dass in einem Verzeichnis alle Logfiles liegen, sodass man z.B. nach Datum sortieren kann, welches zuletzt geändert wurde.


    Naja was heißt aufwendig? Die Ordner und Berechtigungsstruktur könnte man in Sekunden durch ein Script erstellen lassen. Für das Auswerten der Logs könnte man theoretisch auch eine Autoit GUI schreiben, die dir Rekursiv alle Logfiles auflistet und evtl. sogar noch deren Inhalt auswertet, Statistiken zu den von dir zu versteckenden Infos wie "User Aktivität" erstellt usw. :D

    PS: Ich habe oben zum "ERSTELLER-BESITZER" Vorschlag vorhin noch etwas editiert falls du es übersehen hast...

  • Wenn du wieder in der Firma bist teste ob diese Func:

    für deine Zwecke funktioniert.

    3 Mal editiert, zuletzt von autoBert (20. Februar 2016 um 00:41) aus folgendem Grund: Funktionsbescreibung und Errorhandling eingefügt

    • Offizieller Beitrag

    Ich würde ganz klar die bereits angesprochene "Abholversion" favorisieren.
    Die Logs werden lokal gespeichert.
    Auf dem Server legst du einen administrativen Dienst an, der in Intervallen die Logs bei den Usern checkt. Gibts was Neues, wird das abgeholt und auf den Server übernommen.
    Nach dem Muster sammle ich zum Bsp. als PDF gedruckte Dokumente bei meinen Usern ein und archiviere diese auf dem Server. So bleibt der User immer nur in seinem lokalen Space, Rechteprobleme gibt es nicht.

  • Aufgrund der Datenschutzbedenken würde ich das Namensschema der Log-Dateien dahin ändern, dass keine Rückschlüsse auf den Nutzer gemacht werden kann. Ebenfalls würde ich die NTFS-Berechtigung anpassen, dass der Benutzer auf seine Protokolldatei lesenden und schreibenden Zugriff erhält.

    Um Ordner und Dateien auszublenden, auf die ein Benutzer keine Zugriffsrechte hat, würde ich zusätzlich ABE (Zugriffsbasierte Aufzählung) auf den Dateiserver aktivieren.

    Genaue Einstellungen würde ich morgen nachmittag testen.

    Zu guter Letzt sollte dieses mit dem Betriebs- oder Personalrat geklärt sein.