Zugrifsrechte unter XP/2003

[andreas]

Hallo Leute,

hat jamand schon Zugriffs-Probleme mit Datenbanken gehabt, die von dem Programm angelegt werden. Z.B. temporäre Dateien für die Ausdrucke.
Das Problem besteht darin, dass ich temporäre Dateien unter c:\temp auf dem Terminalserver oder local unter XP erzeuge. Bei dem ersten mal funktioniert es einwandfrei. Wenn ich versuche, die Datei 2. mal zu erstellen, wird mir Zugriff durch das System verweigert. Ich habe die Zugriffsrechte kontrolliert und festgestellt, dass die Datei den Administrator als Besitzer hat und ich selber keinen Zugriff darauf habe. Den muss ich mir erst manuell erteilen, dann funktioniert alles wieder.
Wie kann es sein, dass mein Programm in Windows unter meiner Anmeldung die Dateien mit Administratorrechten anlegt?

[Gerd König]

Hallo Andreas,

wir hatten auch schon einmal das gleiche Problem.

Wir starten grundsätzlich unsere Applikationen unter einem anderen Nutzer. Nur dieser spezielle Nutzer hat Zugriff zu den Daten des Netzwerkes.

Wir legen verschiedene Dateien lokal an (z.B. Reports). Das funktioniert bezüglich des Überschreibens dieser Dateien nur, wenn dieser User lokale Administrationsrechte hat. Das ist nicht automatisch unter XP der Fall.

Überprüfe doch mal die Rechte das Users der Applikation auf der lokalen Maschine.

Gruß
Gerd

[Markus Walter]

Hallo Andreas,

sollte eigentlich nicht so sein...

Kann es sein, dass der Benutzer zwischenzeitlich gelöscht und neu angelegt wurde? Das wäre so ein Szenario...

Ich erzeuge temp. Dateien immer im Lokalen Temp-Verzeichnis des Users (kann man mit einer API-Funktion abfragen). Damit hatte ich noch nie Probleme...

PS:Unter Vista wird es noch schöner...

[brandelh]

Dateien immer im Lokalen Temp-Verzeichnis des Users (kann man mit einer API-Funktion abfragen).

Dieses Verzeichnis ist auch in der Umgebungsvariable TEMP gespeichert, also einfach getenv("TEMP") aufrufen ...

[Tom]

Auf Environment-Variablen würde ich mich nie verlassen, die kann man nämlich leichterdings verändern. Diese Funktion liefert das Benutzer-Tempverzeichnis zurück:

Code: Alles auswählen

FUNCTION GetTempPath()
LOCAL nBuffSize := 261
LOCAL sBuffer := Replicate(chr(0),261)
LOCAL cMyTempPath
GetTempPathA(nBuffsize, @sBuffer)
cMyTempPath := Trim(StrTran(sBuffer,chr(0),''))
RETURN cMyTempPath

DLLFUNCTION GetTempPathA( buffsize, @buffer ) ;
         USING STDCALL ;
          FROM KERNEL32.DLL

Noch ein Hinweis: Wenn man solche Funktionen häufiger benutzt, ist es nicht empfehlenswert, sie jedes Mal mit einem DllLoad() und DllUnLoad() zu versehen.

[brandelh]

Auf Environment-Variablen würde ich mich nie verlassen, die kann man nämlich leichterdings verändern.

Im Prinzip ja, aber nur im Programm selbst oder in einer CMD-Box genau für diese. Nur die Programme die dann in dieser Box gestartet werden sehen die geänderten Daten. Wenn das Programm normal gestartet wird, erhält es die Umgebungsvariabeln, die in der Registry gesetzt sind.
Es sei denn man arbeitet noch mit Win98

Wenn man solche Funktionen häufiger benutzt, ist es nicht empfehlenswert, sie jedes Mal mit einem DllLoad() und DllUnLoad() zu versehen.

Wie macht man es dann besser ?

Der mehrfache DllLoad() Aufruf scheint laut Doku kein Problem zu sein.
Kann man dann einfach auf dllunload() verzichten und das Programm später schließen ?
Wird dann die DLL automatisch beim Programmende entladen ?

[andreas]

Die Benutzer sind Domänen-Benutzer, die auch schon etwas länger existieren.
Das komischste ist, dass die Dateien mit den Recten des Administrators und dem Besitzer "Administrator" angelegt werden, obwohl der Domänen-Benutzer angemeldet ist und keine Admin-Rechte hat.

Das mit dem User-Temp-Verzeichnis muss ich es erst ausprobieren. Dafür muss ich aber mein Programm umbauen.

[Rolf Ramacher]

Hallo Andreas,

bei unserem Programm ist dies folgendermaßen gelöst. Unsere Anwender
stellen in der Systemkonfiguration fest, in welchem Ordner sich Texte, ect
Dinge abgespeichert werden sollen. In diesem Ordner dann lege ich die Datenbank ab und wird von dort zum Drucken benutzt.

[Günter Beyes]

<off_topic>

Tom hat folgendes geschrieben:

Wenn man solche Funktionen häufiger benutzt, ist es nicht empfehlenswert, sie jedes Mal mit einem DllLoad() und DllUnLoad() zu versehen.

Hubert hat folgendes geschrieben:

Wie macht man es dann besser ?

Der mehrfache DllLoad() Aufruf scheint laut Doku kein Problem zu sein.
Kann man dann einfach auf dllunload() verzichten und das Programm später schließen ?
Wird dann die DLL automatisch beim Programmende entladen ?

Ein klares Ja zu beidem

Die folgende Variante ist mein persönlicher Favorit, weil ca. 20 Mal schneller als DLLFUNCTION .. USING ... FROM.

Code: Alles auswählen

FUNCTION GetTempPath( buffsize, buffer )

STATIC GetTempPath
IF GetTempPath = NIL
	GetTempPath := DllPrepareCall("KERNEL32.DLL", DLL_STDCALL, "GetTempPathA" )
ENDIF

RETURN DllExecuteCall( GetTempPath, buffsize, @buffer  )

<off_topic>

Viele Grüße,
Günter

[Tom]

Hallo, Günter.

So mache ich's auch, aber ich wollte einen möglichst allgemeingültigen Code posten.

[Markus Walter]

Man könnte doch auch das Ergebnis der Funktion gleich in einer STATIC ablegen oder besteht die Gefahr, dass sich der Temp-Path eines Benutzers während der Laufzeit des Programmes ändert?

[brandelh]

Man könnte doch auch das Ergebnis der Funktion gleich in einer STATIC ablegen oder besteht die Gefahr, dass sich der Temp-Path eines Benutzers während der Laufzeit des Programmes ändert?

Hallo,

wenn er Zugriff auf die Systemsteuerung hat (ich glaube ab Hauptbenutzer ?), könnte er das tun. Aber einer offenen Datei kann niemand das Laufwerk wegnehmen.

[Manfred]

Hi,

der Temppath dürfte sich eigentlich nicht zwischendurch ändern, da es dazu eine Neuanmeldung des User erfordern sollte. (Umgebungsvariablen)