[erledigt] Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Antworten
LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

[erledigt] Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 00:30:21

Hallo Community,

in den Dateien /usr/share/applications/thunderbird.desktop und /usr/share/applications/firefox-esr.desktop sind jeweils in der Zeile Exec=... absolute Pfadangaben

Ich hätte erwartet, dass dort nur der Programmname mit Paramter, z.B. Exec=thunderbird %u und Exec=firefox-esr %u steht und der Pfad zum Programm über das FHS eindeutig ist.
Dann hat man nämlich die Möglichkeit, ohne weitere Änderung in /usr/local/bin ein ausführbares Script thunderbird zu speichern, ohne weitere Änderungen vornehmen zu müssen. In dem Script kann man dann Vorarbeiten und Nacharbeiten machen, bevor man /usr/bin/thunderbird %u explizit aufruft.

Warum enthalten manche Datein *.desktop absolute Pfadangaben, manche nicht?
Sind das Bugs oder Features?

Viele Grüße
Zuletzt geändert von LinuxFanKR13 am 31.03.2021 12:38:45, insgesamt 1-mal geändert.

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von reox » 29.03.2021 09:13:04

Ich hätte vermutet, dass es genau den Zweck erfüllt eben NICHT ein Programm aus /usr/local/bin aufzurufen. Sonst könnte ein Angreifer, der in einen Ordner der in $PATH liegt schreiben kann und vor /usr/bin abgearbeitet wird, ein anderes programm dort ablegen.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 09:29:51

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 00:30:21
Ich hätte erwartet, dass dort nur der Programmname mit Paramter, z.B. Exec=thunderbird %u und Exec=firefox-esr %u steht und der Pfad zum Programm über das FHS eindeutig ist.
Dann hat man nämlich die Möglichkeit, ohne weitere Änderung in /usr/local/bin ein ausführbares Script thunderbird zu speichern, ohne weitere Änderungen vornehmen zu müssen. In dem Script kann man dann Vorarbeiten und Nacharbeiten machen, bevor man /usr/bin/thunderbird %u explizit aufruft.
Das hätte ich ebenso erwartet und ist bei den meisten Programmen auch der Fall.
LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 00:30:21
Warum enthalten manche Datein *.desktop absolute Pfadangaben, manche nicht?
Sind das Bugs oder Features?
Ich vermute, es ist Gedankenlosigkeit oder nicht zuende gedachte Bequemlichkeit. Einen Bugreport, mit genau der Begründung die du hier vorgetragen hast, halte ich für gerechtfertigt.

reox hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 09:13:04
Ich hätte vermutet, dass es genau den Zweck erfüllt eben NICHT ein Programm aus /usr/local/bin aufzurufen. Sonst könnte ein Angreifer, der in einen Ordner der in $PATH liegt schreiben kann und vor /usr/bin abgearbeitet wird, ein anderes programm dort ablegen.
Um in /usr/local/bin Änderungen vorzunehmen sind root-Rechte nötig. Wenn sich ein Angreifer bereits auf dem Level bewegen kann, dann hast du (auch) ganz andere Probleme als umgebogene Starter.
Ähnliches gilt, wenn du Verzeichnisse in $PATH aufnimmst, in denen ein kompromittierter User Schreibrechte hat.

atarixle
Beiträge: 341
Registriert: 20.02.2006 19:30:37

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von atarixle » 29.03.2021 09:41:03

Möglicherweise hat das debian-Team entschieden, auf das eigene Thunderbird-Paket absolut zu verweisen für den Fall, dass man sich den Linux-Build von der Thunderbird-Webseite zusätzlich installiert. K.A. wieso man das machen sollte, aber besser haben und nicht brauchen als brauchen und nicht haben.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 10:08:49

In /usr/share/applications/firefox-esr.desktop steht diese Zeile:

Code: Alles auswählen

Exec=/usr/lib/firefox-esr/firefox-esr %u
/usr/lib steht allerdings standardmäßig nicht in $PATH:

Code: Alles auswählen

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Ich vermute, dass der absolute Pfad in der .desktop-Datei einfach nur ein Workaround um das $PATH-Thema ist. Die Altermnativen wären:
1. /usr/lib/ in $PATH aufnehmen.
2. einen Wrapper um /usr/lib/firefox-esr/firefox-esr stricken, der in $PATH liegt.
3. /usr/lib/firefox-esr/firefox-esr irgendwo in $PATH ablegen. Am naheliegendsten wäre /usr/bin. Und Überraschung:

Code: Alles auswählen

$ ls -l /usr/bin/firefox-esr 
lrwxrwxrwx 1 root root 30 Mär 24 10:52 /usr/bin/firefox-esr -> ../lib/firefox-esr/firefox-esr
Der Wrapper ist also in Form eines Symlinks schon da - nur genau andersrum. Bleibt die Frage: Warum?

LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 11:17:25

Hallo an alle,

Danke für die Antworten.

Also für mich gehören alle Programme, die von der Distribution kommen, nach /usr/bin. Dass firefox-esr im Verzeichnis /usr/lib/firefox-esr liegt, ist mir erst mal egal, weil es ja den Link in /usr/bin gibt, wie hikaru ja auch schreibt (firefox-esr -> ../lib/firefox-esr/firefox-esr)

Code: Alles auswählen

$ echo $PATH
$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
In der Pfadvariable steht die Reihenfolge der Verzeichnisse, in denen nach ausführbaren Programmen und Scripte gesucht wird. Jeder Benutzer hat u.U. ein eigenes Verzeichnis ~/bin, um dort seine eigenen Scripte oder, wer programmiert, seine eigen-entwickelten Programme abzulegen. Alles gut.

Werden "Fremdpakete" installiert, so kann das nach /usr/local/bin oder /opt erfolgen. Dann muss sich aber auch wieder der admin darum kümmern, wenn solche Programme für alle Nutzer zur Verfügung stehen sollen. Ansonsten kann ein User immer noch ~/bin nutzen.
*.desktop mit absoluten Pfadangaben ist auch nach Euren Anmerkungen für mich nun endgültig ein Bug. Da ich noch nie einen Bugreport an Debian-Paketbetreuer geschickt habe, muss ich erst schauen, wie man das macht.

Im Übrigen ist (also als root)

Code: Alles auswählen

# echo $PATH
/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
hier ist also noch jeweils sbin drin. Das passt auch.

Vielen Dank für die Diskussion und allen eine schöne Woche

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von JTH » 29.03.2021 12:52:36

Ich denke mir, dass in den Exec=-Zeilen mal absolute Pfade, mal nur Kommandos stehen, ist eine Mischung aus Flüchtigkeit, Dateien, die einfach von Upstream übernommen wurden und vereinzelten konkreten technischen Gründen.

Schaut man sich beim firefox(-esr) zum Beispiel die Geschichte der .desktop-Datei im Paket an, findet man die Änderung, die dort den /usr/lib-Pfad eingesetzt hat. Dort wurde ein konkretes Problem gelöst Debian Bugreport832298.

reox hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:03:49
Die wenigsten starter haben absolute Pfade drin.
Ja, das hab ich bei mir auch so beobachtet. Nur ~10% der Dateien benutzen absolute Pfade. Davon einige, wie schon erwähnt, mit Pfaden, die nicht im PATH sind.
Zuletzt geändert von JTH am 29.03.2021 13:23:39, insgesamt 3-mal geändert.
Manchmal bekannt als Just (another) Terminal Hacker.

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von reox » 29.03.2021 13:03:49

hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 09:29:51
Um in /usr/local/bin Änderungen vorzunehmen sind root-Rechte nötig. Wenn sich ein Angreifer bereits auf dem Level bewegen kann, dann hast du (auch) ganz andere Probleme als umgebogene Starter.
Gut ich meine es muss ja auch kein Angreifer sein. Den Pfad dort absolut anzugeben macht Sinn, wenn die Gefahr besteht, dass jemand einen Thunderbird von woanders ebenfalls (systemweit) installiert - zB direkt von Mozilla nach zB /opt. Dann soll der Starter ja weiterhin den debian thunderbird starten und nicht durch umgebogene PATH variablen den in /opt.
Wobei keine Ahnung - was will man denn dann wirklich genau... :| (eigentlich gibts ja dafür wohl das alternatives system...)

Es scheint tatsächlich eher Willkür zu sein. Unter einem CentOS hab ich grad geschaut und dort ist firefox auch ohne Pfad im exec.
Die wenigsten starter haben absolute Pfade drin.

LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 13:36:27

Hallo reox, Hallo Community,

wenn wir mal von einem nicht-gehackten System ausgehen, dann kann der normale User keine systemweiten Programme bereitstellen. Er kann nach /usr/bin, /usr/local/bin und /opt nichts installieren. Soll er nicht, braucht er nicht, für systemweite Programme ist der admin zuständig, sonst keiner.
Auf einem Rechner im privaten Bereich ist oft der Nutzer auch der Admin, aber dann schlüpft dieselbe Person eben zeitweise in die andere Rolle.
Der Nutzer kann in seinem ~/bin alles installieren, da kommt aber niemand ohne weiter Anpassungen hin. Ich müsste als anderer Nutzer mindestens meine $PATH anpassen, dass die Programme des anderen in dessen ~/bin aufgerufen werden.

Für mich ist daher klar *.desktop-Dateien sollten keine absoluten Pfadangaben enthalten, weil Programme der Distribution in /usr/bin liegen. Und der Admin kann für den Rechner genutzte lokale Anpassungen über /usr/local/bin allen Nutzern zur Verfügung stellen.

Sollte ein Nutzer stellvertretend für den Admin systemweite Programme, z.B. eigen-entwickelte Software vielen Nutzern bereitstellen, dann muss der Admin z.B. in /opt ein Verzeichnis für genau diesen Zweck zur Verfügung stellen, z.B. für eine Gruppe "Developer". Und dann wird über /etc/skel/.bashrc die ~/.bashrc so ergänzt, dass in $PATH das Verzeichnis in /opt/... dafür erweitert wird. Das sind dann aber alles Eingriffe, die über die Nutzung von Programmen der Distribution hinaus gehen.

Ebenfalls absolute Pfadangaben habe ich bei
- chromium
- thunderbird

Viele Grüße

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 13:41:26

reox hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:03:49
Den Pfad dort absolut anzugeben macht Sinn, wenn die Gefahr besteht, dass jemand einen Thunderbird von woanders ebenfalls (systemweit) installiert - zB direkt von Mozilla nach zB /opt.
Ich würde ja sagen, dass jemand der Thunderbird an der Debian-Paketverwaltung vorbei installiert dafür gute Gründe hat, denen er sich auch bewust ist. Und dieser jemand möchte dann auch sicher seine "mühevoll" installierte Spezialversion standardmäßig starten und nicht das, was ihm Debian vorsetzt. Andernfalls hätte er sich die Mühe wohl nicht gemacht.

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von reox » 29.03.2021 13:56:42

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:36:27
Das sind dann aber alles Eingriffe, die über die Nutzung von Programmen der Distribution hinaus gehen.
Ja stimmt, ihr habt Recht - das ist dann sicherlich kein Standardfall mehr und ich vermute auch, dass die Debian Maintainer nicht diesen nicht-standardfall vorgreifen wollen.
Da hab ich jetzt wohl ein wenig zu oft um die Ecke gedacht ;)

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von JTH » 29.03.2021 14:09:08

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:36:27
Ebenfalls absolute Pfadangaben habe ich bei
- chromium
- thunderbird
Auch bei den beiden hat es einen konkreten Grund, dass dort absolute Pfade angegeben sind:
Dass das so notwendig ist, ist also anscheinend ein prinzipielles Problem oder eine Eigenheit mancher Desktop-Umgebungen beim Setzen der Standardanwendung für Browser, Mail und co. Wenn du es ändern möchtest, wären also eher die Desktop-Umgebungen Adressaten für Bugreports ;)
Manchmal bekannt als Just (another) Terminal Hacker.

cronoik
Beiträge: 2049
Registriert: 18.03.2012 21:13:42
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von cronoik » 29.03.2021 15:59:49

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:36:27
Für mich ist daher klar *.desktop-Dateien sollten keine absoluten Pfadangaben enthalten, weil Programme der Distribution in /usr/bin liegen. Und der Admin kann für den Rechner genutzte lokale Anpassungen über /usr/local/bin allen Nutzern zur Verfügung stellen.
Sehe ich komplett anders. Absolute Pfade sind fuer mich ein Feature, denn es aendert sich nichts auf dem System was der Admin nicht ausdruecklich anordnet. Warum soll sich das Paket X um die Moeglichkeit kuemmern dass du eventuell eine andere Version noch von Upstream beziehst? Stell dir auch mal den anderen Fall vor. Der Admin stellt eine alternative Version bereit die nur fuer ein bestimmtes Szenario genutzt werden sollte (Uraltintranetwebseite--> alter Browser notwendig fuer korrekte Darstellung). Dann will ich auch nicht das diese alternative Installation automatisch zum Standard wird. In dem Fall muesste ich dann die .desktop Datei des debian Paketes anpassen und noch eine weitere erstellen fuer die alternative Version erstellen.

Wenn du zusaetzlich noch mit anderen Parametern starten willst, musst du eh eine gesonderte .desktop Datei anlegen.
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:41:26
Ich würde ja sagen, dass jemand der Thunderbird an der Debian-Paketverwaltung vorbei installiert dafür gute Gründe hat, denen er sich auch bewust ist. Und dieser jemand möchte dann auch sicher seine "mühevoll" installierte Spezialversion standardmäßig starten und nicht das, was ihm Debian vorsetzt. Andernfalls hätte er sich die Mühe wohl nicht gemacht.
So jemand duerfte aber auch mit dem geschilderten "Problem" umgehen koennen.
Hilf mit unser Wiki zu verbessern!

LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 19:09:23

Hallo cronoik, Hallo Community,

also für mich gibt es nur drei Arten von Nutzern und deshalb sehe ich auch keinen Widerspruch zu dem, was cronoik schreibt. Ich sehe aber, dass das Grundsystem durch absolute Pfade behindert.
  • Der Admin, er stellt das System nach vorher festgelegten und allen Beteiligten bekannten Regeln zur Verfügung. Am Admin vorbei kann nichts im "normalen" System installiert werden. Wenn der Admin über ein Script /usr/local/bin/firefox-esr lokale Vorgaben vor dem Starten von /usr/bin/firefox-esr einfügt, sollte das leicht möglich und nicht durch absolute Pfade "behindert" werden.
  • Vom Admin authorisierte Nutzer mit zusätzlichen Berechtigungen, Programme für alle Nutzer bereit zu stellen. Das wird im Sinne der Stabilität und Verfügbarkeit des Systems der Admin so einrichten, dass im Zweifelsfall das "Grundsystem" nicht beschädigt und die lokalen Regeln ausgehebelt werden können.
  • Normale Nutzer können für sich in ihrem $HOME Programme installieren. Vorausgesetzt, dass man mit dem Rechner Internet-Zugang hat, kann und will der Admin das ja erst mal gar nicht verhindern. Ist ja auch ok, weil vielleicht etwas evaluiert werden soll oder weil sich der Nutzer eigene Scripte schreibt, um seine Arbeit leichter zu erledigen. Sonst hätte der Rechner keinen Internet-Zugang.
cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 15:59:49
Sehe ich komplett anders. Absolute Pfade sind fuer mich ein Feature, denn es aendert sich nichts auf dem System was der Admin nicht ausdruecklich anordnet.
Aber genau darum geht es doch. Der Admin "ordnet" über /usr/local/bin etwas an und das Grundsystem behindert den Admin, indem absolute Pfade in /usr/share/applications/*.desktop verwendet werden. Ein anderer als der Admin kann in /usr/local/bin sowieso nichts "anordnen".
cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 15:59:49
Stell dir auch mal den anderen Fall vor. Der Admin stellt eine alternative Version bereit die nur fuer ein bestimmtes Szenario genutzt werden sollte (Uraltintranetwebseite--> alter Browser notwendig fuer korrekte Darstellung).
Genau das habe ich auf meinem System in /usr/local/bin habe ich ein zusätzliches Script intranetbrowser das /usr/bin/firefox-esr mit einer anderen Berechtigung aufruft und eine andere Startseite, nämlich Links auf Intranet, lädt. Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop

Da in der Datei firefox-esr.desktop die Zeile Exec=firefox-esr %u steht (wie zuvor auch) können doch auch Parameter übergeben werden. Und natürlich ist es die Aufgabe des Admin, das Script in /usr/local/bin so zu gestalten, dass die Parameter durchgereicht werden, sonst ist das Script nicht gut genug und sollte verbessert werden.
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:41:26
Ich würde ja sagen, dass jemand der Thunderbird an der Debian-Paketverwaltung vorbei installiert dafür gute Gründe hat, denen er sich auch bewust ist. Und dieser jemand möchte dann auch sicher seine "mühevoll" installierte Spezialversion standardmäßig starten und nicht das, was ihm Debian vorsetzt. Andernfalls hätte er sich die Mühe wohl nicht gemacht.
Wer ist in Deinem Fall dieser jemand?
Der Nutzer kann in seinem $HOME das ja machen. - Wo ist das Problem?
Nur wenn er es allen Nutzern "aufdrücken" will, so ist dies ein Gebot der sinnvollen Zusammenarbeit, dies in Absprache mit dem Admin zu machen (siehe oben, welche Art von Nutzer). Und wenn ich Admin, Nutzer mit besonderern Berechtigungen und "normaler" Nutzer in Personalunion bin, bin ich jederzeit mit mir beschlussfähig :-).

Ist es richtig, dass die Eintragungen bei chromium und thunderbird vor 4 bzw. vor 10 Jahren gemacht wurden? Wenn ich das richtig interpretiert habe, stelle ich die Frage, ob dies nach dieser langen Zeit noch erforderlich ist.
Ich habe die genannten *.desktop-Dateien jedenfalls nach /usr/local/share/applications/*.desktop.orig verschoben und in /usr/local/share/applications/*.desktop identische Dateien ohne absolute Pfadangaben bereit gestellt und bisher keine Probleme feststellen können. Nervig ist nur, dass mit jedem Update wieder /usr/share/applications/*.desktop installiert werden, die dann wieder beseitigt werden müssen.
Bei anderen Programmen ohne absolute Pfade in *.desktop funktioniert das wie gewünscht, Updates sind ohne manuelle Nacharbeit möglich und das zugehörige Script in /usr/local/bin funtioniert auch.

Viele Grüße

curt123
Beiträge: 704
Registriert: 19.10.2018 12:49:35
Wohnort: NRW

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von curt123 » 29.03.2021 19:52:23

Hallo
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 09:29:51
Um in /usr/local/bin Änderungen vorzunehmen sind root-Rechte nötig. Wenn sich ein Angreifer bereits auf dem Level bewegen kann, dann hast du (auch) ganz andere Probleme als umgebogene Starter.
Ähnliches gilt, wenn du Verzeichnisse in $PATH aufnimmst, in denen ein kompromittierter User Schreibrechte hat.
Ich habe recht unterschiedliche Empfehlungen gefunden, wo selbstgeschriebene Skripte, zumal wenn sie im Pfad liegen sollen, hingehören. Momentan landen die hier meistens in /usr/local/bin, auch wenn es bei Änderungen umständlicher ist. So ist es wohl i.d.R. besser, als ein Verzeichnis unter /home/user in den Pfad zu nehmen, oder gibt es da bessere Möglichkeiten / Konventionen?

JTH
Moderator
Beiträge: 3014
Registriert: 13.08.2008 17:01:41
Wohnort: Berlin

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von JTH » 29.03.2021 19:52:47

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Ich habe die genannten *.desktop-Dateien jedenfalls nach /usr/local/share/applications/*.desktop.orig verschoben
Den Schritt kannst du dir wahrscheinlich sparen. Wenn in /usr/share/applications eine .desktop mit exakt demselben Namen wie eine in /usr/local/share/applications existiert, sollte die erstere ignoriert und nur die letztere verwendet werden:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#desktop-file-id hat geschrieben: If multiple files have the same desktop file ID [=filename], the first one in the $XDG_DATA_DIRS precedence order is used.
Der Standardwert von XDG_DATA_DIRS gibt obiges her, nämlich dass Dateien in /usr/local/share jenen in /usr/share vorgezogen werden:

Code: Alles auswählen

~$ echo $XDG_DATA_DIRS
/usr/share/gnome:/usr/local/share/:/usr/share/

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop
Benenn die doch mal in firefox-esr.desktop um und guck, ob alles wie gehabt, gewollt und oben beschrieben weiter funktioniert. Und spar dir dann die extra Arbeit in /usr/share/applications bei Updates.

Nebenbei: Wäre zum Ändern der Startseite nicht eine Konfig für den FF in /etc sinnvoller? (Ich meine, da gibt es Wege.)
Zuletzt geändert von JTH am 29.03.2021 20:30:36, insgesamt 1-mal geändert.
Manchmal bekannt als Just (another) Terminal Hacker.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 20:19:30

cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 15:59:49
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 13:41:26
Ich würde ja sagen, dass jemand der Thunderbird an der Debian-Paketverwaltung vorbei installiert dafür gute Gründe hat, denen er sich auch bewust ist. Und dieser jemand möchte dann auch sicher seine "mühevoll" installierte Spezialversion standardmäßig starten und nicht das, was ihm Debian vorsetzt. Andernfalls hätte er sich die Mühe wohl nicht gemacht.
So jemand duerfte aber auch mit dem geschilderten "Problem" umgehen koennen.
Ja, dürfte er. Die Frage ist, welches Verhalten so jemand bevorzugen würde.

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Wer ist in Deinem Fall dieser jemand?
Du vielleicht? Du hast nicht genau verraten was du vor hast, aber prinzipiell würde jeder der die Standardkonfiguration des Systems verändern möchte, das gern mit möglichst geringem Aufwand tun.
LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Der Nutzer kann in seinem $HOME das ja machen. - Wo ist das Problem?
Möglicherweise steht das System nicht unter Kontrolle des Nutzers und /home ist mit noexec gemountet. Dann ist er auf die Kooperation von root angewiesen um sein Programm zu bekommen. Das dürften typischerweie echte Mehrbenutzersysteme sein und root auf solchen Systemen möchte tendenziell möglichst wenig wegen spezieler Nutzerwünsche am System rumschrauben.

cronoik
Beiträge: 2049
Registriert: 18.03.2012 21:13:42
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von cronoik » 29.03.2021 20:43:28

LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Aber genau darum geht es doch. Der Admin "ordnet" über /usr/local/bin etwas an und das Grundsystem behindert den Admin, indem absolute Pfade in /usr/share/applications/*.desktop verwendet werden. Ein anderer als der Admin kann in /usr/local/bin sowieso nichts "anordnen".
Ich sehe darin keine Behinderung. Paket A wird installiert und bringt eine .desktop Datei mit. Jetzt installiere ich eine andere Version dieser Software (sagen wir B) und ich empfaende es als voellig falsch wenn die .desktop Datei aus A nun zum Starten von B genutzt werden kann. Denn das heisst naemlich auch, dass wenn ich A deinstalliere, verschwindet der Starter von B.

Ich wuerde deiner Ansicht zustimmen wenn es ein Paket gebe das alle .desktop Dateien ausliefert, aber da die .desktop Dateien im jeweilen Paket sind ist meine Erwartungshaltung das auch nur die Sachen aus dem Paket genutzt werden.
LinuxFanKR13 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:09:23
Genau das habe ich auf meinem System in /usr/local/bin habe ich ein zusätzliches Script intranetbrowser das /usr/bin/firefox-esr mit einer anderen Berechtigung aufruft und eine andere Startseite, nämlich Links auf Intranet, lädt. Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop
Das ist aber ein anderes Szenario. Ich hatte eher im Sinn das ich Firefox 2.X fuer etwas benoetige und ausrolle. Es waere doch fatal wenn jetzt jeder Nutzer ueber seinen firefox starter diese Version starten wuerde weil dort relative Pfade verwendet werden wuerden (wir gehen jetzt mal von Namensgleichheit der Dateien aus). Natuerlich ist es meine Aufgabe als Admin mich darum zukuemmern, ich sehe hier relative Pfade aber eher als Fallstrick.
curt123 hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 19:52:23
Ich habe recht unterschiedliche Empfehlungen gefunden, wo selbstgeschriebene Skripte, zumal wenn sie im Pfad liegen sollen, hingehören. Momentan landen die hier meistens in /usr/local/bin, auch wenn es bei Änderungen umständlicher ist. So ist es wohl i.d.R. besser, als ein Verzeichnis unter /home/user in den Pfad zu nehmen, oder gibt es da bessere Möglichkeiten / Konventionen?
/usr/local/bin ist da schon der richtige Weg. [1] Falls es sich aber um ein Einbenutzersystem handelt, dann spricht doch auch nichts um eine einmalige PATH Erweiterung ueber die ~/.profile.

[1] https://www.pathname.com/fhs/pub/fhs-2. ... OCALSHARE1
Hilf mit unser Wiki zu verbessern!

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von hikaru » 29.03.2021 21:13:23

cronoik hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 20:43:28
Paket A wird installiert und bringt eine .desktop Datei mit. Jetzt installiere ich eine andere Version dieser Software (sagen wir B) und ich empfaende es als voellig falsch wenn die .desktop Datei aus A nun zum Starten von B genutzt werden kann. Denn das heisst naemlich auch, dass wenn ich A deinstalliere, verschwindet der Starter von B.
Das ist ein guter Punkt!
Die .desktop-Datei wird von einem Paket ausgeliefert. Eine Fremdsoftware mit GUI sollte saubererweise eine eigene .desktop-Datei mitbringen. Wenn die aber beide an gleicher Stelle landen, dann gibt es einen Zuständigkeitskonflikt.
Würde man das mit Debian-Paketen probieren, indem man z.B. ein unsauberes Fremdrepo einbindet, das in einem anderen Paket (ohne Conflicts:) die gleichen Dateien aiusliefert, dann meckert apt, weil es nicht die gleiche Datei aus zwei Paketen akzeptiert.
Man könnte das sauber lösen, indem das Fremdpaket z.B. alles nach /usr/local instaliert, inklusive seiner .desktop-Datei. Dann ist es auch wieder egal ob in der Datei unter /usr/share/applications ein Pfad steht.

Unschön finde ich es trotzdem, dass offizielle Debian-Pakete .desktop-Dateien mit Pfaden für Binaries auslieferrn.

LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 29.03.2021 22:27:47

Hallo zusammen,
hikaru hat geschrieben: ↑ zum Beitrag ↑
29.03.2021 21:13:23
Das ist ein guter Punkt!
Die .desktop-Datei wird von einem Paket ausgeliefert. Eine Fremdsoftware mit GUI sollte saubererweise eine eigene .desktop-Datei mitbringen. Wenn die aber beide an gleicher Stelle landen, dann gibt es einen Zuständigkeitskonflikt.
Dagegen ist doch auch gar nichts einzuwenden. Ein Paket der Distribution installiert seine ausführbare Datei nach /usr/bin und seine .desktop-Datei nach /usr/share/applications. Durch Vermeidung von absoluten Pfaden in der *.desktop-Datei ermöglicht das Paket dem Admin das Ergänzen von Pre- und Post-Conditions über gleichnamige Scripte in /usr/local/bin. Nicht mehr und nicht weniger. Es geht ja gar nicht darum, ein anderes Paket zu installieren, sondern nur darum, das Programm aus der Distribution "lokal-angepasst" zu nutzen. Wenn die *.desktop-Datei absolute Pfade enthält, muss der Admin zusätzlich eine *.desktop-Datei erzeugen, was eigentlich unnötig ist. Und das habe ich als "Behinderung" des Admins beschrieben.

Ein ganz anderes Paket bringt seine eigene ausführbare Datei (mit anderem Namen) und eigener .desktop-Datei mit.
Wo soll es da einen Zugriffskonflikt geben, wenn jedes Paket/Programm seinen eindeutigen Namen hat?

Ich werde mal testen, ob ich die *.desktop-Datei mit absoluten Pfaden in /usr/share/applications belassen kann und nur die /usr/local/share/applications/*.desktop brauche. Dann ist der Aufwand für *.desktop-Dateien mit absoluten Pfaden "nur" ein einmaliger, aus meiner Sicht dennoch unnötiger Aufwand.

Wenn /home mit noexec gemountet ist, dann stellt der Admin ein - hoffentlich vorher an alle Beteiligten kommuniziertes - System zur Verfügung, das den Nutzern nicht erlaubt, ausführbare Dateien in ihrem $HOME zu haben. Dies ist dann eine andere Policy und hat mit dem beschriebenen Thema nichts zu tun.

Meine /usr/local/share/applications/intranetbrowser.desktop ruft firefox-esr mit dem "normalen" User auf und ist so eingestellt, dass es nur auf das Intranet zugreift und nicht nach draußen geht. Es könnte auch ein "alter Browser" sein, der aus Kompatibilitätsgründen noch benötigt wird.
/usr/local/bin/firefox-esr ruft hingegen /usr/bin/firefox-esr unter einem anderen User auf, so dass das Programm nicht an die Daten des Users heran kommt.

Viele Grüße

LinuxFanKR13
Beiträge: 78
Registriert: 19.04.2020 10:01:02

Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben

Beitrag von LinuxFanKR13 » 31.03.2021 12:37:27

Hallo Community,

ich habe geprüft, dass es in der Tat genügt, zusätzlich zu den /usr/share/applications*.desktop-Dateien mit absoluten Pfadangaben unter /usr/local/share/applications/*.desktop gleichnamige Dateien ohne absolute Pfadangaben bereit zu stellen. Dann werden diese in die Menüs übernommen und per /usr/local/bin/script kann man den Programmnamen "überladen".

Fazit:
Absolute Pfade in *.desktop-Dateien sind für mich nach wie vor nicht sinnvoll, aber der Aufwand für die Korrektur ist eine einmalige Aktion, wenn ein neues Paket installiert wird, nicht aber wenn ein bereits vorhandenes Paket ein Update erfährt, das nichts Grundlegendes ändert.

Vielen Dank für die Unterstützung und viele Grüße

Antworten