ein Fass nach dem anderen geht auf

[Codehunter]

Zitat von jaenicke:

Zitat von Codehunter:

In meinen Augen darf es keinen Unterschied machen, WO ein Programm installiert ist. Die Systemsicherheit muss sich immer gleich verhalten.

Wie das rein theoretisch funktionieren sollte erschließt sich mir nicht. Unterschiedliche Rechte auf unterschiedliche Ordner und das entsprechende Handling sind doch grundlegend wichtig.

Da bin ich vllt. inzwischen etwas von Linux verwöhnt Stark vereinfacht gesagt, überwacht Windows das Laufzeitverhalten von Anwendungen und greift gelegentlich in u.a. Dateioperationen ein. Wenn ich z.B. in %PROGRAMFILES%\Programmname eine Datei erstellen will, geht das nicht ohne Adminrechte. Nur dummerweise geht das ohne Exception o.ä. vonstatten. Der Schreibversuch geht einfach ins Nirvana (bei Linux würde man sagen /dev/null). Da sucht man schon mal bis man das Problem findet. Genau dieses Verhalten dürfte auch der Grund für diesen Thread hier gewesen sein. Das kann bei großen, alten Projekten mit zugekauften Libs richtig in Arbeit ausarten. Ich erinnere mich noch mit Grausen an BDE-Programme mit Paradox-Datenbanken, die mit im Programme-Ordner lagen, wo selbst bei reinen Lesezugriffen immer noch in irgendwelchen Indexdateien geschrieben wurde.

Bei Linux erbt eine Programminstanz ihre Zugriffsrechte ausgehend vom ELF-Objekt. Versucht man aus so einer Instanz einen schreibenden Resourcenzugriff auf ein Objekt, das keine Übereinstimmung bei den schreibenden Zugriffsrechten hat (User und/oder Gruppe), wird das verweigert. So ein "geht ein bisschen" Schreiben wie bei Windows gibts da nicht. Geht oder geht nicht, mit geordnetem Fehler-Handling.

EDIT als Ergänzung zum Verständnis, worin der Vorteil von Linux in dem Fall liegt: Wenn mein Programm seine Konfigurationsdateien ablegt, egal wo, dann erben die die selben Zugriffsrechte vom ELF-Objekt. Wenn jetzt ein fremdes Programm daher kommt, das in seinem eigenen Userspace agiert (Standardverhalten), dann kann es auf die Konfigurationsdateien meines Programms nicht zugreifen. Und dieser programmübergreifende Schutz ist bei Windows eben abhängig vom Installationspfad mehr oder weniger stringent, bei Linux überall gleich.

[himitsu]

Zitat:

einfach ins Nirvana

Nein?

Erstmal kann man im System, sowie auch im Programm derartige Redirections deaktivieren
und auch nicht immer wird umgeleitet. Das hängt z.B. vom Manifest ab (oder vom Dateinamen, wie z.B. "Setup") ob und welche "Abwärtskompatibilitäten" aktiv sind.


Und das ganze wurde nunmal eingebaut, damit alte "schrottige" Programme weiterhin funktionieren, wovon es leider zuviel gab/gibt.
Dass viele Entwickler und auch Endanwender damals oft mit Adminrechten arbeiteten und somit schon lange existierende Sicherheitsmaßnahmen/Beschränkungen umgangen, das war bissl blöd.
Und dass es zuviele "schlaue" Programmmierer gab, die Pfade hartgecoded hatten, zu einer Zeit als Pfade lokalisiert wurden und die sich über die Zeit auch mal änderten ... tja, pech.

[Codehunter]

Zitat von himitsu:

Das hängt z.B. vom Manifest ab (oder vom Dateinamen, wie z.B. "Setup")

Noch so eine Seuche! Stell dir mal vor wie es wäre, wenn eine Setup.exe SELBST nachprüft ob sie Adminrechte (vgl. "su" bei Linux) hat, anstatt ein Pappschild (Manifest) mit der Aufschrift "Bitte liebes System, gib mir mal Adminrechte" vor sich her zu tragen. Und wenns diese Rechte nicht hat, verlangt es danach. Diese Rechte vergäbe der User (bei Linux mit einem "sudo") und nicht das System.

Ein solches Setup würde die Dateien auf die verschiedenen Ordner verteilen und mit den korrekten Zugriffsrechten versehen (geerbt vom sudo aufrufenden Benutzer). Dann wäre es völlig Banane, ob diese Dateien nun in C:\Program Files oder C:\Users\... liegen, dein Programm hätte überall Zugriff darauf.

Damit sind wir nämlich beim entscheidenden Punkt: Bei Windows gibt es inzwischen Instanzen (z.B. SYSTEM) mit höheren Rechten, als jemals ein Anwender erlangen kann. Selbst als Admin stößt du immer wieder auf Dinge, wo dir der "Zugriff verweigert" wird. Ein Unding.

Schreibst du Systemdienste, dann laufen die bei Windows im SYSTEM-Kontext. Schreibst du einen Daemon für Linux, dann läuft der mit genau den Rechten, die ihm auf Dateiebene zugewiesen wurden. Schon mal versucht, mit einem Non-Admin-Programm unter Windows auf Dateien schreibend zuzugreifen, die dein eigener (!!!) Dienst erstellt hat?

Zitat von himitsu:

Und das ganze wurde nunmal eingebaut, damit alte "schrottige" Programme weiterhin funktionieren, wovon es leider zuviel gab/gibt.

Exakt. Windows NT 3.1 hatte das ursprünglich nicht und IMHO bis NT 5.0 (das gabs wirklich! Irgendwo habe ich noch eine Installation aus 1997 davon) auch nicht. Erst mit Windows 2000 wurde das Sicherheitskonzept abgeschwächt, um die 9x-User rüber zu locken. Ein harter Schnitt wäre damals die bessere Wahl gewesen, den man aus Marketinggründen nicht gewagt hat. Über die Jahre wurde dann ungleich mehr Supportaufwand reingesteckt als nötig gewesen wäre, hätte man es gleich richtig gemacht (ist ja oft so)

Deshalb finde ich es unfair, diesen inkonsistenten Murks den Entwicklern vorzuwerfen, die wie in diesem Fall seit 30 Jahren ein Projekt pflegen und das evtl. schon wie vom TE beschrieben ein eigenes Ökosystem bildet.

Um wieder auf das Eingangsthema zurück zu kommen und mich einigen Vorrednern anzuschließen: Mit Innosetup lässt sich das recht elegant lösen. Es gibt auch grafische IDEs dafür, z.B. Inno Script Studio (kostenlos) oder Install Designer (50 Euro), sodass der Lernaufwand überschaubar bleibt.

[himitsu]

Wie gesagt, das kommt drauf an.

Kleines Beispiel zum Selbstausprobieren:
* neue VCL-Anwendung erstellen und Setup.exe nennen
* in den Projektoptionen das Manifest entfernen (Ohne)
* kompilieren
* und ins Verzeichnis gucken C:\Users\%Username%\Documents\Embarcadero\Studio\Projekte\Win32\Debug
* Es wird im Programm-Icon vom Explorer ein Overlay eingeblendet (das Schutzschild) und beim Start geht der UAC auf
* nun das Manifest wieder aktivieren (Automatisch)
* neu erzeugen
* im Explorer verschwindet das Schutzschild-Overlay und der UAC meldet sich auch nicht mehr
* jetzt im Manifest die Ausführungsebene ändern (Admnistrator erforderlich)
* neu erzeugen
* schon ist UAC und Overlay wieder da, aber nicht wegen dem Namen, sondern weil du es beantragt hast

Emba hat inzwischen das Manifest aufgemotzt und unter Anderem auch die <supportedOS>-Abschnitte aufgenommen, wodurch diese Heuristiken nicht aktiviert werden.



Auch ohne Admin-Manifest kann man auch im Windows sowas selbst machen.
Wie sudo gibt es hier das runas oder auch andere Dinge.

[Codehunter]

Zitat von himitsu:

Kleines Beispiel zum Selbstausprobieren:
* neue VCL-Anwendung erstellen und Setup.exe nennen
* in den Projektoptionen das Manifest entfernen (Ohne)
* kompilieren
* und ins Verzeichnis gucken C:\Users\%Username%\Documents\Embarcadero\Studio\Projekte\Win32\Debug
* Es wird im Programm-Icon vom Explorer ein Overlay eingeblendet (das Schutzschild) und beim Start geht der UAC auf
* nun das Manifest wieder aktivieren (Automatisch)
* neu erzeugen
* im Explorer verschwindet das Schutzschild-Overlay und der UAC meldet sich auch nicht mehr
* jetzt im Manifest die Ausführungsebene ändern (Admnistrator erforderlich)
* neu erzeugen
* schon ist UAC und Overlay wieder da, aber nicht wegen dem Namen, sondern weil du es beantragt hast

Lach... Ja das sind so lustige Eigenheiten die mich von Windows vertrieben haben. Ist ein Programm automatisch böser, nur weil es Setup.exe heißt? Warum zeigt sich dieses Verhalten nicht, wenn ich es Malware.exe nenne? Oder umgekehrt, warum wird ein böseres Programm als weniger böse dargestellt, nur weil es nicht Setup.exe heißt? Irgendwie ist das doch eine Mischung aus Pseudosicherheit und Benutzerkomfort.

Gut bei Linux gibt es etwas ähnliches wie das Manifest. Hier wird z.B. eine Datei dadurch zur ausführbaren Datei, dass man ihr ein bestimmtes Dateiattribut gibt. Der Name ist dagegen völlig irrelevant. So kannst du auch reine Textdateien ausführbar machen und das System versucht dann anhand des Dateiinhaltes, die entsprechende Laufzeitumgebung (bash, perl, python u.ä.) zu finden.

Aber wir kommen vom Thema ab. Ich kritisiere ja nur das seltsame Windows-Verhalten, die Sicherheit von bestimmten Ordnern abhängig zu machen. Dann versucht man bei Altprojekten genau das, was der TE beschrieben hat: Anpassung an die Microsoft-Vorgaben. Was bei Altprojekten aber oft schwierig ist und in der Folge mehr als nötig in Ordnern mit weniger Sicherheit landet, eben %APPDATA% usw. Das ja, wie schon richtig bemerkt, in Domänenumgebungen dazu führt, dass die Serverprofile vollgemüllt werden und die Windowsanmeldung ewig dauert, weil erstmal alles gesynct werden muss.

Zitat von jaenicke:

Zitat von Codehunter:

Damit sind wir nämlich beim entscheidenden Punkt: Bei Windows gibt es inzwischen Instanzen (z.B. SYSTEM) mit höheren Rechten, als jemals ein Anwender erlangen kann. Selbst als Admin stößt du immer wieder auf Dinge, wo dir der "Zugriff verweigert" wird. Ein Unding.

Besitzer ändern, fertig...

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant".

Zitat von jaenicke:

Zitat von Codehunter:

Schreibst du Systemdienste, dann laufen die bei Windows im SYSTEM-Kontext.

Wenn du das so einstellst, ja. Unsere Dienste laufen nicht alle im System-Kontext, sondern teilweise auch im Benutzerkontext.

Das soll, zumindest was den Desktop-Datenaustausch angeht, demnächst nicht mehr möglich sein. Der Trend geht eher zu Hintergrundprogrammen, die per Taskplaner verwaltet werden. Wieder so eine Baustelle, die sich für die Betreuer von Altprojekten auftun wird.

[jaenicke]

Zitat von Codehunter:

Lach... Ja das sind so lustige Eigenheiten die mich von Windows vertrieben haben. Ist ein Programm automatisch böser, nur weil es Setup.exe heißt? Warum zeigt sich dieses Verhalten nicht, wenn ich es Malware.exe nenne? Oder umgekehrt, warum wird ein böseres Programm als weniger böse dargestellt, nur weil es nicht Setup.exe heißt?

Es geht doch nicht um gut oder böse. Es wird nur davon ausgegangen, dass eine Setup.exe ohne aktuelles Manifest eventuell Adminrechte benötigt, aber zu alt ist um das passende Manifest zu haben, und deshalb werden diese dann automatisch angefordert. Das geht doch nur darum, dass der Benutzer ältere, nicht für das neue System erstellte, Software weiter nutzen kann.

Eine Setup.exe mit aktuellem Manifest, sprich eine, die für das aktuelle System gemacht wurde, bekommt diese Kompatibilitätsanpassung nicht.

Es hat halt alles Vor- und Nachteile. Bei macOS oder Linux funktioniert ein Tool ggf. einfach ein paar Jahre (oder auch schon bei anderen Distributionen^^) nicht mehr (oft genug selbst erlebt), bei Windows wird es mit der Abwärtskompatibilität dafür schon eher übertrieben. Aber dafür kann man selbst 16-Bit Windows 1.0 Programme noch 35 Jahre später unter Windows 10 32-Bit nutzen... und auch noch ältere MS-DOS Programme funktionieren grundsätzlich noch.

Zitat von Codehunter:

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant".

Wo ist da aber der praktische Anwendungsfall? Also wozu sollte man das können?

[Codehunter]

Zitat von jaenicke:

... bei Windows wird es mit der Abwärtskompatibilität dafür schon eher übertrieben. Aber dafür kann man selbst 16-Bit Windows 1.0 Programme noch 35 Jahre später unter Windows 10 32-Bit nutzen... und auch noch ältere MS-DOS Programme funktionieren grundsätzlich noch.

Das meine ich ja. Irgendwann hat mich diese Mischung aus Kompatibilitätsballast, wiederkehrende Update-Probleme, Microsofts Misstrauen ggü. dem User und das zunehmende "Phoning Home" von Windows vertrieben (privat wie gesagt). Anfangs war es schwierig aber dann machte der harte Cut richtig Spaß. Bei Linux hilft bei störrischen Altprogrammen auch schon mal ein simples Recompile und Linken gegen die aktuellen Bibliotheken. Hängt natürlich stark vom Einzelfall ab. Shellprogramme sind da unkomplizierter als GTK und Qt.

Zitat von jaenicke:

Zitat von Codehunter:

Das meine ich nicht. Geh mal als Admin in die Systemverwaltung und versuche, gewisse Microsoft-Dienste zu beenden. Keine Chance. Und mir soll keiner erzählen, die wären "systemrelevant".

Wo ist da aber der praktische Anwendungsfall? Also wozu sollte man das können?

Warum sollte man das nicht dürfen? Das meine ich mit Misstrauen ggü. dem User. Der praktische Anwendungsfall? Ein Beispiel: Dualboot auf einem betagten Laptop, Windows 10 und Linux Mint 20. Die selbe Maschine läuft mit einer Akkuladung unter Windows 90 Minuten und unter Linux 8,5 Stunden, Leerlauf, einfach nur das nackte System jeweils frisch installiert. Also guckt man, was da die lieben Stromtierchen verscheucht und landet bei diversen Hintergrunddiensten, die man weder braucht noch dass sie für den Systembetrieb (die Hauptaufgabe eines Betriebssystems!) notwendig sind. Mit Bordmitteln sind sie durch Normaluser nicht abschaltbar, muss man mit Fachwissen über die Registry machen. Am Ende läuft das Windows 5 Stunden über den Akku. Und die Moral von der Geschicht: Der alte Rechner ist nicht perse ungeeignet für Windows 10, sondern es ist nur out of the Box viel zu fett und unflexibel. Die Philosophie ist maximaler Funktionsumfang, notfalls um den Preis einer Neuanschaffung. Und die Querverzahnung zwischen den Diensten macht es zunehmend schwerer, daran noch etwas zu ändern, selbst wenn man das notwendige Fachwissen hat. Im privaten Bereich mag das Spielerei sein, im professionellen Bereich sind das handfeste Argumente in Bezug auf die TCO.

Zitat von freimatz:

Zitat von Codehunter:

Deshalb finde ich es unfair, diesen inkonsistenten Murks den Entwicklern vorzuwerfen, die wie in diesem Fall seit 30 Jahren ein Projekt pflegen und das evtl. schon wie vom TE beschrieben ein eigenes Ökosystem bildet.

Danke. Hilft zwar nicht tut aber gut.

Ich denke wir hatten nur beide mal das Bedürfnis uns auszukotzen

[jaenicke]

Zitat von Codehunter:

Noch so eine Seuche! Stell dir mal vor wie es wäre, wenn eine Setup.exe SELBST nachprüft ob sie Adminrechte (vgl. "su" bei Linux) hat, anstatt ein Pappschild (Manifest) mit der Aufschrift "Bitte liebes System, gib mir mal Adminrechte" vor sich her zu tragen. Und wenns diese Rechte nicht hat, verlangt es danach. Diese Rechte vergäbe der User (bei Linux mit einem "sudo") und nicht das System.

Das ist ja möglich, wird nur in der Regel nicht gemacht, weil es meistens keinen Sinn hätte die Rechte selbst zu prüfen. Und eine Adminkonsole vorher aufmachen und dann das Setup starten oder runas aufrufen um den Nutzer anzugeben kann man auch unter Windows. Einfacher ist aber, wenn man schlicht den Dialog von Windows bestätigt. Und deshalb ist das auch der Standard für normale lokale Installationen...

Zitat von Codehunter:

Ein solches Setup würde die Dateien auf die verschiedenen Ordner verteilen und mit den korrekten Zugriffsrechten versehen (geerbt vom sudo aufrufenden Benutzer).

Wer bestimmt denn, dass das "korrekt" ist? Ich möchte z.B. nicht, dass die beim Setup gesetzten Voreinstellungen durch den Benutzer geändert werden können, die des Benutzers darf er aber ändern. Möglich ist so etwas mit dem Windows Installer durchaus.
Und es gibt ja auch extra die Trennung zwischen Daten für alle Benutzer und für bestimmte, wenn du ein Setup erstellst.

Zitat von Codehunter:

Damit sind wir nämlich beim entscheidenden Punkt: Bei Windows gibt es inzwischen Instanzen (z.B. SYSTEM) mit höheren Rechten, als jemals ein Anwender erlangen kann. Selbst als Admin stößt du immer wieder auf Dinge, wo dir der "Zugriff verweigert" wird. Ein Unding.

Besitzer ändern, fertig...

Zitat von Codehunter:

Schreibst du Systemdienste, dann laufen die bei Windows im SYSTEM-Kontext.

Wenn du das so einstellst, ja. Unsere Dienste laufen nicht alle im System-Kontext, sondern teilweise auch im Benutzerkontext.

Zitat von Codehunter:

Schon mal versucht, mit einem Non-Admin-Programm unter Windows auf Dateien schreibend zuzugreifen, die dein eigener (!!!) Dienst erstellt hat?

Ja, machen wir öfter. Damit hatten wir bisher keine Probleme. Man muss halt die Rechte entsprechend vergeben oder den Dienst im gewünschten Kontext ausführen, egal ob unter Windows oder Linux. Nur die Logik ist eben je nach System unterschiedlich.

[freimatz]

Zitat von Codehunter:

Deshalb finde ich es unfair, diesen inkonsistenten Murks den Entwicklern vorzuwerfen, die wie in diesem Fall seit 30 Jahren ein Projekt pflegen und das evtl. schon wie vom TE beschrieben ein eigenes Ökosystem bildet.

Danke. Hilft zwar nicht tut aber gut.