Process_Terminate funktioniert nicht

[Luckie]

Ich dachte du hättest neue Benutzerkonten eingerichtet? Spielt er jetzt doch wieder unter einem Administratorkonto? Dir ist aber klar, dass er dann dein Programm einfach beenden kann und das war es dann wieder mit der Zeitlichen Begrenzung. Und glaub mir es wird nicht lange dauern, dann hat er es gefunden und wenn er einen Freund um Hilfe bitte, der sich damit auskennt.

Gerade probiert mit einem eingeschränkten Benutzerkonto, unter dem man so wie so nur arbeiten sollte) funktioniert es nämlich nicht mehr. Da werden nur alle offenen Anwendungen beendet.

[speedy]

Ja hab ich. Er hat einen Account mit Zeitbeschränkung zum spielen und einen Account zum surfen und arbeiten. Beides sind eingeschränkte Accounts ohne Admin-Rechte. Wenn das normal nicht laufen sollte ist es aber ne gute Frage wieso es auf der Kiste unter dem normalen Benutzer trotzdem funktioniert. Hab das zigmal ausprobiert und es wurde immer schön abgemeldet.

Das er es beenden kann weiß ich, da kommt er aber zum Glück nicht so schnell drauf. Falls doch, bleibt da wohl nur noch ein zusätzliches Programm (oder Dienst) der überwacht ob die Überwachung läuft und das Tool ggf. wieder startet.

[Luckie]

Halt, stopp. Ich habe gerade Abmelden mit Runterfahren verwechselt. Abmelden sollte gehen.

[Assarbad]

Zitat:

Zitat von speedy (Beitrag 1064893)

Wofür das mit $FFFF... hab ich von hier: http://www.delphi-library.de/topic_W...en_8272,0.html

:shock: ... typischer Fall von Cargo Cult Programming, würde ich sagen.

[speedy]

Ja dann wär die Frage ja geklärt ;)

Hab mir das mal mit dem Dienst (der als Local System läuft) überlegt, der die Zeitüberwachung "schützt". Müsste da ja quasi zuerst prüfen ob der entsprechende Benutzer gerade angemeldet ist (nur wie ist die Frage... über ein Programm den aktuellen Benutzer auszulesen ist ja kein Thema aber als Service?), anschließend ob die Überwachung läuft und wenn nicht den Prozess mit sowas wie CreateProcessAsUser starten. Hab da zum CreateProcessAsUser nur gelesen, dass man dazu das Benutzerkennwort braucht. Würde dann natürlich schief gehen, wenn das Passwort mal geändert werden sollte.

[Luckie]

Zitat:

Zitat von speedy (Beitrag 1064909)

(nur wie ist die Frage... über ein Programm den aktuellen Benutzer auszulesen ist ja kein Thema aber als Service?)

Forensuche.

Zitat:

Hab da zum CreateProcessAsUser nur gelesen, dass man dazu das Benutzerkennwort braucht. Würde dann natürlich schief gehen, wenn das Passwort mal geändert werden sollte.

Das wäre ja auch eine ziemliche Sicherheitslücke, wenn man einem Benutzer einfach so einen Prozess unterschieben könnte. Stelle dir vor du könntest einen Administrator einen Prozess unterschieben, der liefe dann im Kontext des Administrator mit allen Rechten und Privilegien.

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1064910)

Das wäre ja auch eine ziemliche Sicherheitslücke, wenn man einem Benutzer einfach so einen Prozess unterschieben könnte. Stelle dir vor du könntest einen Administrator einen Prozess unterschieben, der liefe dann im Kontext des Administrator mit allen Rechten und Privilegien.

Irrtum, und vor allem geht es ;)

Ein Dienst ist Teil der TCB, wie du wissen solltest. Und als solcher (und mit SYSTEM-Rechten) kann man sich auch ein Token selberbasteln ;) ... ganz ohne Paßwort (zugegebenermaßen ist das im Netzwerk meines Wissens nach nicht viel wert).

CreateProcessAsUser basiert übrigens selber auf einem Dienst ("Zweitbenutzeranmeldung" oder wie das Ding heißt ..., wenn ich mich recht entsinne).

[Luckie]

Echt? Das überrascht mich jetzt aber. Aber gut, man lernt nie aus.

[speedy]

Das is richtig, aber hat ein Dienst, der standardmäßig als Local System läuft, nicht auch sämtliche Rechte und Privilegien wie ein Administrator? Abgesehen von der Interaktivität mit dem User-Desktop. Ein Programm das direkt vom Dienst aufgerufen wird erbt ja quasi dann die Local System Rechte.

Oder bring ich da jetzt was durcheinander?

[Assarbad]

Zitat:

Zitat von speedy (Beitrag 1064914)

Das is richtig, aber hat ein Dienst, der standardmäßig als Local System läuft, nicht auch sämtliche Rechte und Privilegien wie ein Administrator? Abgesehen von der Interaktivität mit dem User-Desktop. Ein Programm das direkt vom Dienst aufgerufen wird erbt ja quasi dann die Local System Rechte.

Nein, du hast recht. Aber ab Vista gibt es noch ein kleines anderes Problem. Stichwort: Session Separation. ... da wird es dann schon relativ kompliziert aus einem Dienst etwas in den Benutzerdesktop zu injizieren (unmöglich ist es aber nicht).

Zitat:

Zitat von Luckie (Beitrag 1064913)

Echt? Das überrascht mich jetzt aber. Aber gut, man lernt nie aus.

Nebbett hatte glaube ich auch ein Beispiel in seinem Buch zur NT/2000 Native API, falls du nachlesen willst. Schick ggf. ne PM (oder Email).

[Luckie]

Das Buch wollte ich schon immer mal haben. Aber meine letzte Suche war nicht sehr erfolgreich. Kann es sein, dass es nicht mehr aufgelegt wird?

[speedy]

Hab das mal unter Win7 testweise ausprobiert und als Service über ein einfaches ShellExecute mal notepad gestartet. Es kam halt ein Hinweis, der daraufhin nen Desktop von Local System mit Notepad geöffnet hat. Bei nem Programm das kein sichtbares Fenster hat (Application.ShowMainForm := false) kam dann keine Benachrichtigung.

[Luckie]

Einfach mit Shellexecute kann es nicht funktionieren. Und wenn du dich mal etwas mit Diensten beschäftigst, wirst du auch wissen warum das nicht gehen kann.

[speedy]

Wenn wir grad bei Büchern sind. Kennt die Reihe einer von euch und kann mir sagen ob die halbwegs was taugen? Die gäbs in der Uni Bibliothek...

http://www.amazon.de/Win32-ComCtl32-.../dp/3932311051

Und doch... hat definitiv funktioniert mit

Delphi-Quellcode:

ShellExecute(0,nil,pchar('c:\windows\notepad.exe'),nil,nil,0);

sofern ShellAPI eingebunden wird.

[Luckie]

Also jetzt bin ich mir definitiv sicher. Das ein Programm mit Shellexecute aus einem Service gestartet der Benutzer nie zu Gesicht bekommen wird.

[speedy]

Sehen tut der Benutzer das auch nicht. Es gibt halt unter Win7 (Vista wohl auch) eine Benachrichtigung. Man kann sich dann das Programm auf einem getrennten Desktop (ohne Taskleiste usw.) anzeigen lassen.

[Luckie]

OK, wie Windows 7 das jetzt Hand habt, kann ich nicht sagen. Aber das soll ja unter XP laufen und da gibt es keine Benachrichtigung und keine Möglichkeit zu dem Desktop mit dem gestarteten Programm zu wechseln.

Und was das Buch angeht. hast du dir mal die Kritiken durchgelesen und auf das Erscheinungsdatum geguckt? Das Buch ist mittlerweile 13 Jahre alt.

[Assarbad]

Zitat:

Zitat von speedy (Beitrag 1064919)

Wenn wir grad bei Büchern sind. Kennt die Reihe einer von euch und kann mir sagen ob die halbwegs was taugen? Die gäbs in der Uni Bibliothek...

http://www.amazon.de/Win32-ComCtl32-.../dp/3932311051

Jo, hatte mir damals alle Bücher zugelegt. Aber da steht auch nicht mehr als im PSDK von vor 1013 Jahren drin. Also wenn du des Englischen mächtig bist, benutze stattdessen das PSDK (jetzt "Windows SDK") von Microsoft.

@speedy: die Benachrichtigung gibt es nur wenn ein bestimmter Dienst läuft der das ermöglicht. Auf meinem Windows 7 heißt der Dienst: "Erkennung interaktiver Dienste" (C:\Windows\system32\UI0Detect.exe)

[speedy]

Ach du meintest das bezogen auf das Überwachungsprogramm. Das hat eh kein sichtbares Fenster.

Aber man hätte mit ShellExecute sowieso das Problem, dass die Überwachung als System ausgeführt wird und nicht mehr nur unter dem zeitbeschränkten Benutzer läuft. Hätte voraussichtlich die Folge, dass die Zeit bis zum automatischen Abmelden unter sämtlichen Accounts runterzählt und am Ende versucht wird, das ExitWindowsEx auch als System auszuführen... Daher müsste der Prozess vom Service eben dem bestimmten User untergeschoben werden. Dann mal rausfinden was es mit dem Token basteln auf sich hat. ;)

Wird ja sowieso erst nötig, wenn der Zocker rausfinden sollte was er tun muss um die Überwachung abzuschießen.

[Assarbad]

Aber nochmal zur Zeitbeschränkung. Gab es das nicht als Einstellung beim Benutzerkonto selber? Haste ein Windows XP Home oder Pro?

Ah, kurze Suche: hier. Da scheint jemand ein ähnliches Problem mit dem Kind zu haben :zwinker:

[speedy]

XP Pro hab ich ihm drauf. XP besitzt da laut langer Suche im Netz nur die Möglichkeit Anmeldezeiten festzulegen (über net ...)

D.h. ich kann festlegen dass er sich z.B. Mo-Fr von 15 - 17 Uhr, Sa + So von 15 - 19 Uhr einloggen kann. Das ist aber nicht das was ich will. Er soll sich schon selbst aussuchen können wann er zockt. Nur die maximale Dauer soll festgelegt werden.

Ob Vista oder Win7 beim "Kinderschutz" da mehr können hab ich jetzt nicht geschaut, aber kommt eh nicht in Frage weil der Rechner dafür zu schwach ist.

[Assarbad]

Zitat:

Zitat von speedy (Beitrag 1064927)

D.h. ich kann festlegen dass er sich z.B. Mo-Fr von 15 - 17 Uhr, Sa + So von 15 - 19 Uhr einloggen kann. Das ist aber nicht das was ich will. Er soll sich schon selbst aussuchen können wann er zockt. Nur die maximale Dauer soll festgelegt werden.

Das kann man aber durchaus kombinieren, denke ich. Diese Woche schon Zeitguthaben verbraucht, nunja dann sperrt dein Dienst (nur als Beispiel) eben das Konto oder setzt die Zeiten entsprechend restriktiv.

Aber hast vermutlich recht. Erstmal gucken wie er sich macht. Ist es XP Pro mit SP2 oder SP3? Wenn ja, könnte man ja versuchen nen (Mini-)Filtertreiber zusammenzuflicken. Das wird dann mit dem Umgehen schon schwerer.

[speedy]

Jo... bin so mit dem mal eben unter Zeitdruck zusammengeflickten Programm für den Anfang schon ganz zufrieden :)

Bin mir jetzt nicht sicher aber müsste XP SP2 sein.