[erledigt] Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
[erledigt] Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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
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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Das hätte ich ebenso erwartet und ist bei den meisten Programmen auch der Fall.LinuxFanKR13 hat geschrieben:29.03.2021 00:30:21Ich 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.
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.LinuxFanKR13 hat geschrieben:29.03.2021 00:30:21Warum enthalten manche Datein *.desktop absolute Pfadangaben, manche nicht?
Sind das Bugs oder Features?
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.reox hat geschrieben:29.03.2021 09:13:04Ich 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.
Ähnliches gilt, wenn du Verzeichnisse in $PATH aufnimmst, in denen ein kompromittierter User Schreibrechte hat.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
In /usr/share/applications/firefox-esr.desktop steht diese Zeile:
/usr/lib steht allerdings standardmäßig nicht in $PATH:
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:Der Wrapper ist also in Form eines Symlinks schon da - nur genau andersrum. Bleibt die Frage: Warum?
Code: Alles auswählen
Exec=/usr/lib/firefox-esr/firefox-esr %u
Code: Alles auswählen
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
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
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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)
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)
hier ist also noch jeweils sbin drin. Das passt auch.
Vielen Dank für die Diskussion und allen eine schöne Woche
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
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
Vielen Dank für die Diskussion und allen eine schöne Woche
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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 832298.
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 832298.
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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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.hikaru hat geschrieben:29.03.2021 09:29:51Um 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.
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.
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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
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
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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 hat geschrieben:29.03.2021 13:03:49Den 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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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.LinuxFanKR13 hat geschrieben:29.03.2021 13:36:27Das sind dann aber alles Eingriffe, die über die Nutzung von Programmen der Distribution hinaus gehen.
Da hab ich jetzt wohl ein wenig zu oft um die Ecke gedacht
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Auch bei den beiden hat es einen konkreten Grund, dass dort absolute Pfade angegeben sind:LinuxFanKR13 hat geschrieben:29.03.2021 13:36:27Ebenfalls absolute Pfadangaben habe ich bei
- chromium
- thunderbird
- Use the full path in chromium-browser.desktop Exec fiels (Closes: #580582), 580582
- fix *.desktop files for proper GNOME app mechanism, 817973, 832302
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.
-
- 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
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.LinuxFanKR13 hat geschrieben:29.03.2021 13:36:27Fü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.
Wenn du zusaetzlich noch mit anderen Parametern starten willst, musst du eh eine gesonderte .desktop Datei anlegen.
So jemand duerfte aber auch mit dem geschilderten "Problem" umgehen koennen.hikaru hat geschrieben:29.03.2021 13:41:26Ich 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.
Hilf mit unser Wiki zu verbessern!
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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.
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.
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
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.
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:29.03.2021 15:59:49Sehe ich komplett anders. Absolute Pfade sind fuer mich ein Feature, denn es aendert sich nichts auf dem System was der Admin nicht ausdruecklich anordnet.
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.desktopcronoik hat geschrieben:29.03.2021 15:59:49Stell 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).
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.
Wer ist in Deinem Fall dieser jemand?hikaru hat geschrieben:29.03.2021 13:41:26Ich 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.
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
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Hallo
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?hikaru hat geschrieben:29.03.2021 09:29:51Um 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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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:LinuxFanKR13 hat geschrieben:29.03.2021 19:09:23Ich habe die genannten *.desktop-Dateien jedenfalls nach /usr/local/share/applications/*.desktop.orig verschoben
Der Standardwert von XDG_DATA_DIRS gibt obiges her, nämlich dass Dateien in /usr/local/share jenen in /usr/share vorgezogen 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.
Code: Alles auswählen
~$ echo $XDG_DATA_DIRS
/usr/share/gnome:/usr/local/share/:/usr/share/
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.LinuxFanKR13 hat geschrieben:29.03.2021 19:09:23Und dafür gibt es auch eine eigene /usr/local/share/applications/intranetbrowser.desktop
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.
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Ja, dürfte er. Die Frage ist, welches Verhalten so jemand bevorzugen würde.cronoik hat geschrieben:29.03.2021 15:59:49So jemand duerfte aber auch mit dem geschilderten "Problem" umgehen koennen.hikaru hat geschrieben:29.03.2021 13:41:26Ich 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.
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.
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.LinuxFanKR13 hat geschrieben:29.03.2021 19:09:23Der Nutzer kann in seinem $HOME das ja machen. - Wo ist das Problem?
-
- 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
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.LinuxFanKR13 hat geschrieben:29.03.2021 19:09:23Aber 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 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.
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.LinuxFanKR13 hat geschrieben:29.03.2021 19:09:23Genau 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
/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.curt123 hat geschrieben:29.03.2021 19:52:23Ich 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?
[1] https://www.pathname.com/fhs/pub/fhs-2. ... OCALSHARE1
Hilf mit unser Wiki zu verbessern!
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Das ist ein guter Punkt!cronoik hat geschrieben:29.03.2021 20:43:28Paket 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.
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.
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
Hallo zusammen,
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
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.hikaru hat geschrieben:29.03.2021 21:13:23Das 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.
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
-
- Beiträge: 78
- Registriert: 19.04.2020 10:01:02
Re: Bug oder Feature in /usr/share/applications/*.desktop - absolute Pfadangaben
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
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