ich habe ein Problem beim Betrieb von Portfolio Performance unter linux. Nachdem ich das tar.gz heruntergeladen und nach /usr/local/bin entpackt habe startete es zuerst nicht, mit Verweis auf fehlende Ausführungsrechte von Dateien in meinem /home Verzeichnis (libswt-gtk-4629.so). Soweit so richtig, aus Sicherheitsgründen ist bei mir /home standardmäßig also noexec gemountet. Das ist eine Option für das Dateisystem, welche das Ausführen von Dateien auf dem jeweiligen Datenträger untersagt. Standardmäßig brauchen Anwendungen unter linux keine zwingenden Ausführungsrechte auf dem /home Verzeichnis.
Wenn ich jetzt /home mit der Option exec mounte, kann ich Portfolio Performance zwar ausführen aber das ist etwas unschön, da dadurch mein Sicherheitskonzept ausgehebelt werden muss. Gibt es eine Möglichkeit das zu vermeiden und das Programm auszuführen, ohne an den Sicherheitseinstellungen herum zu schrauben?
Ich muss noch dazu sagen, dass das Programm das einzige ist, welches die Option bisher bei mir benötigte, andere Java Programme (z.b. jstock), die nicht im Repository sind, lassen sich auch ohne exec Rechte auf dem /home Verzeichnis problemlos ausführen. Programme aus dem Repository brauchen das sowieso nicht. Zumindest sind mir keine bekannt.
Ich würde das Programm gerne benutzen aber scheue mich, dafür die Sicherheitseinstellungen herunter zu schrauben, da durch gleich alle Programme auf dem /home Verzeichnis ausgeführt werden können, nicht nur dieses. Und gerade das will ich ja verhindern.
Ach ja, noch was zu meinem System: Debian, 64 Bit, Jessie (8.9)
java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
Damit liegst du nicht ganz auf der Höhe der Zeit. Dein Beispiel funktioniert so seit knapp 10 Jahren nicht mehr. Beweis gefällig?
[14:55:46 root@Leela /]
# mount |grep " /tmp "
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,nodiratime,size=524288k)
[14:55:54 root@Leela /]
# cp -a /bin/uname /tmp
„/bin/uname“ -> „/tmp/uname“
[14:56:01 root@Leela /]
# /lib64//ld-linux-x86-64.so.2 /tmp/uname
/tmp/uname: error while loading shared libraries: /tmp/uname: failed to map segment from shared object: Operation not permitted
[14:56:09 root@Leela /]
# /tmp/uname
bash: /tmp/uname: Keine Berechtigung
[14:56:24 root@Leela /]
# mount -o exec /tmp -oremount
[14:56:30 root@Leela /]
# /lib64//ld-linux-x86-64.so.2 /tmp/uname
Linux
[14:56:33 root@Leela /]
# /tmp/uname
Linux
Das ist ein 64 Bit Betriebssystem, daher habe ich den 64 Bit loader benutzt. Unter 32 Bit funktioniert das allerdings auch seit Ewigkeiten nicht mehr. Es ist im Übrigen auch nur ein Baustein in meinem Sicherheitskonzept.
Mmhhh. Ich bin kein Linux Experte. Ich nutze das Eclipse Framework und kann deshalb recht einfach auch Linux Builds generieren (auf meinem mac). Allerdings hat meine Suche mit “noexec home directory” nicht wirklich was gefunden. (Und Eclipse ist eben keine “normale” Linux Anwendung).
Hier heißt es zum Beispiel - allerdings mit einer anderen Fehlermeldung, aber das Verhalten ist ja identisch:
The problem still there. Although, I found a workaround. Before starting eclipse I execute as root:
mount -o remont,exec /home
Then I start Eclipse and after it is started I can bring things back to normal by executing:
mount -o remount,noexec /home
Das sieht für mich danach aus, als würde Eclipse (PP) eine shared library auspacken und starten wollen. Das sollte aber eigentlich in dem “configuration” Verzeichnis der Installation selber sein. Hat dein User da keine Schreibrechte? Und speichert das Optional unter “home”?
Ansonsten könntest Du das “workspace” Verzeichnis verschieben. Das wird über das Property osgi.instance.area.default in der Date config.ini gesteuert und zeigt normalerweise auf @user.home/.PortfolioPerformance/workspace (zumindest unter Linux).
Unter /usr haben Benutzer unter linux normalerweise keine Schreibrechte, daher auch nicht unter /usr/local/bin (Dort kommen für gewöhnlich lokal installierte Anwendungen hin, die systemweit verfügbar sein sollen.). Und ja, da wurde wohl tatsächlich auf /home ausgewichen. Ich hab die Dateien ja auch bereits entdeckt gehabt. Ich hätte aber nicht erwartet, dass das Programm in sein Instalationsverzeichnis nachträglich noch etwas reinschreibt. Abgesehen davon ist /usr bei mir sowieso read only.
Für gewöhnlich schreiben Programme nach der Installation nur noch einfache Konfigurationsdateien in das /home Verzeichnis. Binäre Dateien sieht man da für gewöhnlich nicht. Ist das nur bei dem ersten Start so oder ist da später noch damit zu rechnen, dass in das configuration Verzeichnis rein geschrieben wird?
Ich habe jetzt mal das Programm nach /opt verschoben, das ist für alle sonstigen Programme gedacht, und dem user Schreibrechte auf das configuration Verzeichnis gegeben. Das führt auch zum gewünschten Ziel. Zumindest weiß ich jetzt, worauf ich achten muss. Ich werde noch ein wenig mit dem workspace Verzeichnis herum spielen, ob ich das irgendwie noch sauberer eingebunden bekomme. Ist halt schön, wenn sich alle Programme gleich verhalten. Insbesondere bei späteren Updates spart man sich da viel Stress. Auf jeden Fall ist mir schon mal etwas geholfen.
Bei einer Online Aktualisierung würde ich weitere Änderungen erwarten: und zwar in dem “plugins” Verzeichnis (neue JAR Pakete) und im “configuration” Verzeichnis (enthält u.a. die ausgepackten JAR Pakete die nativen Code wie SWT enthalten können).
Ich kann Deinen Frust verstehen. Mich stört zum Beispiel auch, dass ich unter macOS das Programm deswegen nicht sauber signieren kann (ich signiere “nur” die Java JAR Pakete) denn keine Signatur überlebt wenn im Installationsverzeichnis Dateien geändert werden.
Ich hab jetzt noch ein wenig herumgespielt, hab´s aber im Moment aufgegeben. Zwar funktioniert das Programm, wenn ich dem Benutzer nur Schreibrechte auf das configuration Verzeichnis gebe, allerdings werden dann bestimmte Funktionen, wie z.B. die Darstellung der Bestände nicht mehr ausgeführt. Es wird eine Fehlermeldung angezeigt, dass das Paket libwebkitgtk-1.0-0 nicht installiert sei. Das liegt aber natürlich vor. Es hapert lediglich an den Zugriffsrechten, da die übrigen Dateien dem Benutzer root gehören. Anscheinend gibt es noch mehr Verzeichnisse, auf die der Benutzer exklusiven Zugriff haben muss.
Das Programm liegt jetzt auf /opt und der Benutzer hat volle Zugriffsrechte. Nach Unix Konventionen eigentlich ein Fremdkörper, aber naja, was soll man machen.
Ich hatte ursprünglich vor, ein Paket für Debian zu bauen (nur so für mich, um es über das Paketmanagement pflegen zu können), als ich das tar.gz gesehen habe aber so wie ich das sehe ist Portfolio Performance anscheinend nicht für Multiuserbetrieb ausgelegt d.h. eine Installation lässt sich nicht von mehreren Benutzen parallel verwenden sondern für jeden Benutzer muss eine volle Installation verfügbar sein. Da erübrigt sich auch der Paketbau, weil sich Portfolio Performance (oder eben halt Eclipse) nicht an die üblichen Konventionen hält. Ich könnte jetzt zwar noch versuchen, das ganze über eine passende Gruppenzugehörigkeit zu lösen aber das fliegt mir dann sicher an einer anderen Stelle auch wieder um die Ohren.
Mmhhh. Ich bin kein Linux Experte. Ich nutze das Eclipse Framework und kann deshalb recht einfach auch Linux Builds generieren (auf meinem mac). Allerdings hat meine Suche mit “noexec home directory” nicht wirklich was gefunden. (Und Eclipse ist eben keine “normale” Linux Anwendung).