Windows-Dienst, Notification, Zugriff verweigert

[himitsu]

Hab ich doch beschrieben?
Kannst'e lesen?

* du bist dafür, dass jeder eine App unsichtbart oder im Tray laufen lässt, selbst wenn die meistens nicht genutzt wird

* ich bin dafür, dass man diese "permanenten" Nachrichten-Apps abschafft und stattdessen der Dienst im Falle des Anzeigewillens den Prozess zum Anzeigen im aktiven Kontext vorübergehend startet,
damit eben nicht sinnlos tausende Anwendungen aktiv sein müssen.

Und ja, das NotificationCenter ist auch nett.
OK, die Komponente von Embarcadero ist schrott, aber per se muß das Programm nicht dauerhaft laufen, nach der Anzeige dort. Wenn sich die Anwendung/Komponente richtig mit der Notification verbunden hätte, würde Windows unser Programm wieder starten, wenn man auf die Notification klickt und das eigene Programm schon wieder weg war.

[Delrabe]

Hallo,

@himitsu: unabhängig davon, was gut oder schlecht ist, die Hauptfrage ist, was geht und was geht nicht. Bei der Version "Dienst startet Notify.App" besteht das Problem, dies auch wirklich durchzuführen. Wie bereits beschrieben, der Dienst verschafft sich das "Token" des aktuellen Users/Contextes und versucht dann die NotifyApp über "CreateProcessAsUser" zu starten. Dies schlägt leider fehl mit einer Meldung über fehlende Rechte. Möglicherweise muß man bei diesem Aufruf noch zusätzliche Parameter einbauen (SecurityAttributes, ThreadAttributes, Environment), aber da bräuchte ich Hinweise, wie genau das geht. Ich habe im Netz schon viel dazu gelesen, aber keine funktionierenden präzisen Hinweise gefunden.

Es wird im übrigen auch "CreateProcessWithLogonW" vorgeschlagen, aber da weiß ich nicht, wie das "gehen" soll, da man ja das Passwort nicht kennt.

[Delrabe]

Hallo,

irgendwie ging meine Antwort von vor einer Stunde verlustig. Daher noch einmal ein Versuch.

Danke für die Anworten. Und sorry, ich bin zwar ein versierter Delphi-Entwickler, habe aber auf diesem Feld noch Defizite.

Wenn die Notify-App also ebenfalls permanent gestartet ist und es "nur" darum geht, dass der Dienst die Notify-App über ein anstehendes Update informiert, dann verstehe ich natürlich auch den Einsatz einer NamedPipe. Und bevor ich mich darin vertiefe, wie in etwa sieht das auf der Seite der Notify-App aus? Die App muß wohl beim Start ein MS-Objekt erzeugen, in dem ein entspr. Handle angefordert wird. Aber wie geht es jetzt weiter? Gibt es dabei irgendeine Form von Event/Message, auf die die App. nur reagieren muß, oder muß die App. ähnlich wie beim Dienst vorgehen, also permanent die Update-Situation prüfen und dann eine kleine Zeit (1000 Milli.Sek.) schlafen.

Inzwischen habe ich allerdings eine andere Idee. Man könnte auch ganz auf einen Dienst verzichten, und stattdessen die Arbeit von einer Kontroll-App. erledigen lassen, die unsichtbar im Hintergrund läuft und im Autostart eingetragen ist, ähnlich wie das jetzt für die NotifyApp vorgeschlagen wurde. Diese Kontroll-App müsste einen Kontroll-Thread erstellen und starten, der permanent eine anstehende Aktion prüft, ggf. einen Client-Thread zur Durchführung startet und anschließend ein kleine Zeit pausiert. Bei dieser Konstruktion sollte das Notify-Problem entfallen, oder?

Ich sehe nur ein Problem, wenn die Sache auf einem Client-Rechner läuft und der angemeldete User nur über geringe Rechte verfügt. Die Kontroll-App. müsste vom Sys-Admin so eingerichtet/installiert werden, dass sie über das Recht verfügt, Daten von unserem Server herunterzuladen, bzw. vorerst würde sogar der Download der entsprechenden Konfig.-Textdatei genügen. Ich weiß leider nicht, was da möglich ist.

[himitsu]

[ups]

[himitsu]

@Delrabe
Dass es geht, beweisen ja mehrere Programme, welche die NotifyApp aus dem Server starten.

Auch kann man im Server einen neuen Thread erstellen, ihn in einen anderen Kontext verschieben und von dort aus auf den Nutzerdesktop zugreifen.
z.B. TeamViewer soll das intern tun, um z.B. die UAC-Passorteingabe anzeigen zu können.

[QuickAndDirty]

Zitat von himitsu:

@Delrabe
Dass es geht, beweisen ja mehrere Programme, welche die NotifyApp aus dem Server starten.

Auch kann man im Server einen neuen Thread erstellen, ihn in einen anderen Kontext verschieben und von dort aus auf den Nutzerdesktop zugreifen.
z.B. TeamViewer soll das intern tun, um z.B. die UAC-Passorteingabe anzeigen zu können.

Ich bin davon überzeugt, dass du recht hast, dass man auf eine Systray-Autostart-App verzichten kann, wenn man es schafft aus dem Dienst heraus eine Meldung auf aktiven Sessions anzeigen kann.
Wie sieht eine solche Methode aus?

Delphi-Quellcode:

Procedure ShowMessageInAllInteractiveSessions(aMessage:String);
Begin
// was muss hier hin damit ein Dienst auf allen interaktiven Sesssions den Messagetext anzeigen kann?
end;

[Sinspin]

Der Name einer Named Pipe ist beiden Programmen bekannt. Über den Name kommt die Verbindung zustande. Der Dienst muss die Named Pipe erzeugen und ihre Rechte anpassen, sonst ist sie außerhalb der des Dienst Desktops sichtbar/erreichbar.
Ich verwende eine Komponente von NSoftware, die den Aufwand für die Nutzung etwas reduziert. Da gibt es sicherlich auch noch andere Lösungen. Oder eben den direkten weg.

Das ist halt immer die Frage, reicht eine Anwendung via Autostart? Oder ist es wichtig das auch in Fällen in denen kein Nutzer angemeldet ist, aber es Zeit wird die Aufgabe zu erledigen, die Aufgabe erledigt werden kann. Dienste laufen mit dem Rechner, Anwenderprogramme erst mit Nutzeranmeldung.

[Delrabe]

Hallo Sinspin,

in meinem Fall würde die Autostart-Version reichen. Sie muß nur funktionieren, insbesondere wenn der angemeldete User nicht über die notwendigen Rechte (z.B. Download) verfügt.

[QuickAndDirty]

Zitat von Delrabe:

Hallo Sinspin,

in meinem Fall würde die Autostart-Version reichen. Sie muß nur funktionieren, insbesondere wenn der angemeldete User nicht über die notwendigen Rechte (z.B. Download) verfügt.

Die Sache ist die, dass man rechte normalerweise in diensten konserviert... sprich..der Admin installiert das Programm...und das Programm installiert einen Dienst der die Sachen ausführt die mehr rechte brauchen.
Der Installer der mit admin rechten läuft (oder eine Erststart der mit Admin rechten läuft) setzt dann den ACL(SDDL) des Dienstes so, dass unprivilegierte Benutzer ihn starten können.

Delphi-Quellcode:

// der erste ist der SD den der Dienst normalerweise hat wenn man ihn nicht anpasst.
//ACL (SDDL )
SECURITY_DESCRIPTOR_STANDARD = 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for administrators
  '(A;;CCLCSWLOCRRC;;;AU)' +               // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRC;;;PU)' +         // default permissions for power users
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // Built IN Users
  '(A;;RP;;;IU)';                          // added permission: start service for interactive users

SECURITY_DESCRIPTOR_ALLOW_START_BY_USER = 'D:' +
  '(A;;CCLCSWRPWPDTLOCRRC;;;SY)' +         // default permissions for local system
  '(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)' + // default permissions for built-in administrators
  '(A;;CCLCSWRPLOCRRC;;;IU)'+              // permissions for interactively logged-on user   von MozillaMaintainance und ChromeElevation
  '(A;;CCLCSWRPLOCRRC;;;SU)'+              // permissions for service logon user  von MozillaMaintainance und ChromeElevation
  '(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BU)'+      // permissions for built-in users
  '(A;;CCLCSWRPLOCRRC;;;AU)' +             // default permissions for authenticated users
  '(A;;CCLCSWRPWPDTLOCRRCRP;;;PU)';        // default permissions for power users

const
  advapi32 = 'advapi32.dll';
  {$IFDEF UNICODE}
  AWSuffix = 'W';
  {$ELSE}
  AWSuffix = 'A';
 {$ENDIF UNICODE}
function ConvertStringSecurityDescriptorToSecurityDescriptorA; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptorA';
function ConvertStringSecurityDescriptorToSecurityDescriptorW; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptorW';
function ConvertStringSecurityDescriptorToSecurityDescriptor; external advapi32 name 'ConvertStringSecurityDescriptorToSecurityDescriptor' + AWSuffix;


Procedure SetServiceSecurityDescriptor(ServiceName,Permission:String);// in ServiceAfterInstall ausführen da hat man immer Admin Rechte.
var
  SA: TSecurityAttributes;
  SvcMgr,SvcHandle: SC_HANDLE;
Begin
  SA.nLength := SizeOf(SA);
  SA.bInheritHandle := True;
  if not ConvertStringSecurityDescriptorToSecurityDescriptor(PWideChar(Permission),
                                                         1,
                                                         SA.lpSecurityDescriptor,
                                                         nil
                                                         ) then RaiseLastOSError;
{$IF DEFINED(CLR)}   //A.R. CLR = Common Language Runtime = .NET
  SvcMgr := OpenSCManager('', nil, SC_MANAGER_ALL_ACCESS);
{$ELSE}
  SvcMgr := OpenSCManager(nil, nil, SC_MANAGER_ALL_ACCESS);
{$ENDIF}
  if SvcMgr = 0 then RaiseLastOSError;
  try
    SvcHandle := OpenService(SvcMgr, PWidechar(ServiceName)  , SERVICE_ALL_ACCESS);
    if SvcHandle = 0 then RaiseLastOSError;
    try
      SetServiceObjectSecurity(SVCHandle,DACL_SECURITY_INFORMATION,SA.lpSecurityDescriptor);
    finally
      CloseServiceHandle(SvcHandle);
    end;
  finally
    CloseServiceHandle(SvcMgr);
  end;
  LocalFree(HLOCAL(SA.lpSecurityDescriptor));
end;

Eine ander Möglichkeit Rechte zu konservieren ist es einen Geplantentask im Taskscheduler zu hinterlegen. Das wollte ich in zukunft mal versuchen... habe es aber bisher noch nie ausgerollt...nur damit experimentiert.