Hallo, je nach Projekt werden auf github verschiedene Arten der Installation angeboten. Bei einem Programm existieren z.B. folgende Möglichkeiten: 1) Package (über ppa): sudo apt install Programmname 2) Pip: pip install --user Programmname 3) Git: git clone https://github.com/Programmname/Programmname.git cd Programmname python setup.py install --user Angenommen ich installiere das Programm z.B. über Pip und möchte später auf eine neuere Version updaten, kann mich aber nicht mehr an die ursprünglich gewählte Installationsart erinnern und wähle eine andere, z.B. Git. Kann sich das ganze dann irgendwie "in die Quere" kommen? Paketabhängigkeiten, Pfade oder ....?
aschafmeister schrieb: > Angenommen ich installiere das Programm z.B. über Pip und möchte später > auf eine neuere Version updaten, kann mich aber nicht mehr an die > ursprünglich gewählte Installationsart erinnern ... ... dann guckst du halt nach. Sowohl apt, als auch pip haben eine entsprechende Funktion.
Wenn Du nicht höllisch aufpasst verlierst Du den Überblick, also übertreibs nicht, mach Dir Notizen was Du getan hast um später nicht lange rumrätseln zu müssen. Versuche immer zuerst das Paket im offiziellen Repository der Distribution zu finden, nur falls gar nicht anders möglich verwende pip oder dergleichen. Verwende dann immer die Option --user (und kein sudo) um Dein System nicht zu zerschießen. Schau Dir auch den virtualenv Mechanismus von Python an und versuche davon Gebrauch zu machen, das ist nämlich ne feine Sache die hilft das Paketgewirr lokal zu begrenzen und vom übrigen System und von anderen Anwendungen oder Projekten vollständig zu isolieren. Oberstes Ziel muss es immer sein Nebenwirkungen und Konflikte mit anderen Python-Programmen und Paketen zu vermeiden die vom System installiert wurden sonst öffnest Du das Tor zur Hölle!
:
Bearbeitet durch User
aschafmeister schrieb: > je nach Projekt werden auf github verschiedene Arten der Installation > angeboten. Nein. Auf Github wird Quellcode angeboten. Verschiedene Möglichkeiten der Installation werden womöglich vorgestellt. Oder erläutert. > Bei einem Programm existieren z.B. folgende Möglichkeiten: > > 1) Package (über ppa): > sudo apt install Programmname Ja. > 2) Pip: > pip install --user Programmname Nein. > 3) Git: > git clone https://github.com/Programmname/Programmname.git > cd Programmname > python setup.py install --user Nein. Alles steht und fällt damit, welche Bedeutung du dem Wort "Installation" beimißt. Linux Systeme haben (im Gegensatz zu z.B. Windows) seit ewigen Zeiten etwas, das sich "Paketmanagement" nennt. Auf debianesken Systemen ist die "apt" Suite dafür zuständig ("apt" steht für "Advanced Package Tool"). Die Verwendung des jeweiligen Paket Managers stellt sicher, daß Abhängigkeiten aufgelöst werden (wenn du ein Paket installierst, werden die dafür notwendigen anderen Pakete automatisch mitinstallliert) und ebenso daß vorhandene Updates gefunden und installiert werden (auf Wunsch auch automatisch). Die beiden anderen Varianten "installieren" ein Paket nur dahingehend, daß es vorhanden ist. Das Paketmanagement hat davon aber jeweils keine Ahnung. Weder kann es erkennen, ob Abhängigkeiten bestehen oder ob Updates existieren. Im Zweifelsfall (z.B. wenn man solche Frage stellt, wie du gerade) dann will man das nicht.
Axel S. schrieb: > Im Zweifelsfall ( Backup vorher hilft. Im Zweifelsfall hast Du das System zerlegt.
aschafmeister schrieb: > je nach Projekt werden auf github verschiedene Arten der Installation > angeboten. > Bei einem Programm existieren z.B. folgende Möglichkeiten: > > 1) Package (über ppa): > sudo apt install Programmname > > 2) Pip: > pip install --user Programmname > > 3) Git: > git clone https://github.com/Programmname/Programmname.git > cd Programmname > python setup.py install --user Nein. Lediglich ersteres Installiert das Paket wirklich (vgl. setup.exe/setup.msi unter Windows). pip ist der Paketmanager von Python, um Module für die Programmiersprache zu installieren. Hat auch mit dem Betriebssystem nichts zu tun (Python gibt es auch für Windows), aber immerhin arbeitet es paketbasierend, wird dir also nach eine Update hoffentlich nicht um die Ohren fliegen. Das ganze arbeitet allerdings (gezwungenermaßen) an deiner OS-Paketverwaltung vorbei, kann also möglicherweise Inkompatibilitäten führen. git kopiert dir wiederum einfach nur Files in ein beliebiges Directory. Das mitgelieferte setup.py kümmert sich um Abhängigkeiten, allerdings wieder über pip, und damit an deinem Betriebssystem vorbei.
xkcd schrieb: > im Zweifel einfach so :) > > https://xkcd.com/1654/ Warum hat er sie mit & verbunden, das ergibt doch keinen Sinn, da führt er sie doch alle gleichzeitig aus! Damit der Witz funktioniert müsste er es mit || verknüpfen: Scheitert das erste dann kommt das nächste, usw., bis es irgendwann klappt und das Script dann dort endet. Oder hab ich den Witz falsch interpretiert?
Bernd K. schrieb: > xkcd schrieb: >> https://xkcd.com/1654/ > ... hab ich den Witz falsch interpretiert? Du versuchst, Sinn zu finden, wo keiner ist.
Hallo, im großen und ganzen sind mir die grundsätzlichen Bedeutungen und Unterschiede, insbesondere hinsichtlich des Paketmanagers, schon klar gewesen. Aber daß das ganze so empfindlich ist, habe ich dann doch nicht erwartet. Daher die möglicherweise naive Frage. > ... dann guckst du halt nach. Sowohl apt, als auch pip haben eine > entsprechende Funktion. Wo gibt es dazu nähere Beschreibungen? Wer merkt sich denn, wie und auf welche Weise er irgendwann mal ein Programm installiert hat?
aschafmeister schrieb: > Aber daß das ganze so empfindlich ist, habe ich dann doch nicht > erwartet. Ist es überhaupt nicht. Du bist hier nur in einem Forum das mit Boomern übersät ist, von daher die empfindlichen Reaktionen. Vor 20 Jahren war der Ansatz, dass eine Linux-Distribution alles kontrolliert, ein guter Ansatz. Die Open-Source-Szene war im Vergleich zu heute winzig, und die Weiterentwicklung der Software langsam. Heute funktioniert das nicht mehr gut. Die großen Dinge (Kernel mit Desktop und den Basics wie Browser) installiert man über die Distro, die mittleren Dinge (die großen Projekte wie Editoren etc.) über irgendwelche PPAs, und die coolen Dinge alle direkt. Es ist Blödsinn, anzunehmen, eine Distribution könnte heute die ganze Opensource-Software in ihr Format pressen und kontrollieren. Das funktioniert heute einfach nicht mehr. Der Kram ist zu viel geworden und entwickelt sich immer schneller weiter. Schon heute ist die konkrete Distribution total uninteressant und in den Hintergrund geraten. Darum werden SNAP und ähnliche Ansätze immer erfolgreicher. In einigen Jahren wird eine setup.bin o.ä. was ganz normales unter Linux sein. Die Linux Plattform wird eben ganz langsam erwachsen.
Experte schrieb: > Es ist Blödsinn, anzunehmen, eine Distribution könnte heute die ganze > Opensource-Software in ihr Format pressen und kontrollieren. Das > funktioniert heute einfach nicht mehr. Der Kram ist zu viel geworden und > entwickelt sich immer schneller weiter. Das tut sie aber und das ist ein Grund für die Stabilität eines Linux Systems. > > Schon heute ist die konkrete Distribution total uninteressant und in den > Hintergrund geraten. Darum werden SNAP und ähnliche Ansätze immer > erfolgreicher. In einigen Jahren wird eine setup.bin o.ä. was ganz > normales unter Linux sein. Das glaube ich kaum. Evt. als user, aber nie als root. > > Die Linux Plattform wird eben ganz langsam erwachsen. Oder genauso chaotisch wie Windows. Hoffentlich nicht. Aber zum Glück kann man noch selbst entscheiden, welchen Murks man sich auf sein System installiert.
Experte schrieb: > Heute funktioniert das nicht mehr gut. Die großen Dinge (Kernel mit > Desktop und den Basics wie Browser) installiert man über die Distro, die > mittleren Dinge (die großen Projekte wie Editoren etc.) über > irgendwelche PPAs, und die coolen Dinge alle direkt. Vielleicht solltest du mal ’ne ordentliche Distri versuchen. Ubuntu (und Ableger) sind eher ’n Negativbeispiel für die Funktionsweise von Distributionen – da kann ich verstehen, dass man da versucht ist, derart drin rumzupfuschen (und am Ende bei einem ähnlich kaputten Gesamtsystem landet, wie’s ein vollgemülltes Windows in der Regel ist). Bei anderen funktioniert’s jedenfalls ganz prima über das Paketmanagement, außerdem ist’s dort oft sehr einfach, auch selbstgebaute Software in das Paketmanagement zu integrieren.
:
Bearbeitet durch User
aschafmeister schrieb: > Wo gibt es dazu nähere Beschreibungen? man apt-get Ansonsten hilft natürlich Gockel > Wer merkt sich denn, wie und auf welche Weise er irgendwann mal ein > Programm installiert hat? alles logs findest Du ordentlich unter /var/log/ speziell das: dpkg.log Jack V. schrieb: > Vielleicht solltest du mal ’ne ordentliche Distri versuchen. Ubuntu (und > Ableger) sind eher ’n Negativbeispiel für die Funktionsweise von > Distributionen Hmm, ich arbeite mit Mint aber kann mich da eigentlich nicht beklagen. Was meinst Du speziell?
Experte schrieb: > In einigen Jahren wird eine setup.bin o.ä. was ganz > normales unter Linux sein. Das wird nie passieren. Der Unterschied zu Linux und Windows ist nämlich, dass das Installationspaket nicht als eigenständiges ausführbares Programm kommt, dass dann Schaden am System anrichten kann, sondern es kommt als reines Datenpaket mit Installationangaben und das Paketsystem des Systems wertet diese aus und installiert dann das Programm entsprechend. Auch SNAP und Co. wertet die Installationspakete mit im SNAP fähigen System schon vorinstallierten Programmen aus. Das macht nicht das Installationspaket selbst.
Nano schrieb: > Experte schrieb: >> In einigen Jahren wird eine setup.bin o.ä. was ganz >> normales unter Linux sein. > > Das wird nie passieren. > Der Unterschied zu Linux und Windows ist nämlich, dass das > Installationspaket nicht als eigenständiges ausführbares Programm kommt, > dass dann Schaden am System anrichten kann, sondern es kommt als reines > Datenpaket mit Installationangaben und das Paketsystem des Systems > wertet diese aus und installiert dann das Programm entsprechend. Das betrifft nur die nachgezogenen Programme und libs. Das eigentliche Programm liegt sehr wohl im .deb paket. > > Auch SNAP und Co. wertet die Installationspakete mit im SNAP fähigen > System schon vorinstallierten Programmen aus. Das macht nicht das > Installationspaket selbst. Doch, in einem Snap ist das komplette Programm incl. libs enthalten. Wenn ich wirklich so etwas mal installieren muß, dann nur ins home mit user Rechten. Oder ggf. ein Subdir in /opt dafür vorsehen.
aschafmeister schrieb: > im großen und ganzen sind mir die grundsätzlichen Bedeutungen und > Unterschiede, insbesondere hinsichtlich des Paketmanagers, schon klar > gewesen. Aber daß das ganze so empfindlich ist, habe ich dann doch nicht > erwartet. Das ist nicht empfindlich. Noch nicht mal "empfindlich". Aber zu einem großen Teil beruht die Stabilität eines Linux-Systems darauf, daß es ein Paketmanagement hat. Man kann das natürlich umgehen, nimmt damit aber eben die genannten Nachteile in Kauf. Deine Wahl. Das ist anderswo ganz ähnlich. Bei VW verlängert sich bspw. die Mobilitätsgarantie, wenn du den Service in einer autorisierten Werkstatt machen läßt. Alternativ kannst du für weniger Geld eine freie Werkstatt beauftragen, verlierst dabei aber die Garantie. Wieder: deine Wahl. > Wer merkt sich denn, wie und auf welche Weise er irgendwann mal ein > Programm installiert hat? Niemand. Genau deswegen die Empfehlung, grundsätzlich immer über den Paketmanager zu gehen. Experte schrieb: > Vor 20 Jahren war der Ansatz, dass eine Linux-Distribution alles > kontrolliert, ein guter Ansatz. Heute funktioniert das nicht mehr gut. Das ist deine Ansicht. Die ich nicht teile. > Es ist Blödsinn, anzunehmen, eine Distribution könnte heute die ganze > Opensource-Software in ihr Format pressen und kontrollieren. Es ist noch viel mehr Blödsinn, das Packaging als "in ein Format pressen und kontrollieren" zu bezeichnen. Es geht einfach nur darum, die Files im Filesystem-Baum als zu einem Package zugehörig zu bezeichnen und ein paar Metadaten wie Abhängigkeiten klarzustellen. Oft ist es ausgesprochen einfach, ausgehend vom Sourcecode ein Package für die eigene Distribution zu bauen. Ich habe hier für meine Debian Installationen jedenfalls eine Menge hausgemachte Packages. Manchmal sind es nur Upgrades für verwaiste Pakete, manchmal enthalten die Packages lokale Patches. Und manchmal ist es Software, für die es keine Debian-Packages gibt, die aber weder nach /opt noch nach /usr/local paßt. > Schon heute ist die konkrete Distribution total uninteressant und in den > Hintergrund geraten. Darum werden SNAP und ähnliche Ansätze immer > erfolgreicher. SNAP ist HipsterscheiXXe. Niemand außer Hipstern findet das cool. Aber eigentlich sind Hipster genuin Jobsisten. Besser ist das. > In einigen Jahren wird eine setup.bin o.ä. was ganz > normales unter Linux sein. Sicher nicht. > Die Linux Plattform wird eben ganz langsam erwachsen. Das ist die merkwürdigste Definition von "erwachsen", von der ich je gehört habe. Ich würde das klar als Rückschritt ansehen. Vielleicht meinst du ja "senil"?
Andreas B. schrieb: > Das betrifft nur die nachgezogenen Programme und libs. Das eigentliche > Programm liegt sehr wohl im .deb paket. > >> >> Auch SNAP und Co. wertet die Installationspakete mit im SNAP fähigen >> System schon vorinstallierten Programmen aus. Das macht nicht das >> Installationspaket selbst. > > Doch, in einem Snap ist das komplette Programm incl. libs enthalten. > Wenn ich wirklich so etwas mal installieren muß, dann nur ins home mit > user Rechten. Oder ggf. ein Subdir in /opt dafür vorsehen. Versuch doch erst einmal zu verstehen was ich geschrieben habe. Das Programm installiert sich bei Snap nicht selbst, sondern es wird installiert. Das ist der große Unterschied zwischen einem Installer, wie man ihn von Windows her kennt und einem Paket, wies es das bei Linux gibt.
Nano schrieb: > > Versuch doch erst einmal zu verstehen was ich geschrieben habe. > Das Programm installiert sich bei Snap nicht selbst, sondern es wird > installiert. > > Das ist der große Unterschied zwischen einem Installer, wie man ihn von > Windows her kennt und einem Paket, wies es das bei Linux gibt. Korrektur, mit "es installiert sich selbst" meine ich den mitgelieferten Installer, da es als ausführbare Datei bei Win kommt. Obiges könnte missverstanden werden.
Nano schrieb: > Versuch doch erst einmal zu verstehen was ich geschrieben habe. > Das Programm installiert sich bei Snap nicht selbst, sondern es wird > installiert. OK, dann habe ich Dich mißverstanden. Wobei der Unterschied bezüglich Sicherheit so groß dann aber nicht ist. Ob ich jetzt eine ausführbares Programm laufen lasse oder ein Paket, welches ausführbare Dateien enthält (die dann eben später ausgeführt werden), macht dann eigentlich keinen Unterschied. Beides muß aus vertrauenswürdigen Quellen stammen. Und genau da sehe ich das eigentlich Problem bei SNAP & Co. Mal davon abgesehen, daß durch das hineinziehen aller libs nur für ein Programm solche SW gigantischen FP Speicher verbraucht. So etwas macht man nur im Notfall.
Andreas B. schrieb: > Nano schrieb: >> Versuch doch erst einmal zu verstehen was ich geschrieben habe. >> Das Programm installiert sich bei Snap nicht selbst, sondern es wird >> installiert. > > OK, dann habe ich Dich mißverstanden. > Wobei der Unterschied bezüglich Sicherheit so groß dann aber nicht ist. > Ob ich jetzt eine ausführbares Programm laufen lasse oder ein Paket, > welches ausführbare Dateien enthält (die dann eben später ausgeführt > werden), macht dann eigentlich keinen Unterschied. Natürlich macht das einen großen Unterschied. Unter Windows fragt dich der Installer bspw. nach Adminrechten, damit er das Programm in einen Ordner schreiben darf, für den er höhere Rechte benötigt. In dem Moment, in dem du dem Installer die Adminrechte gibst, gehört das System der Schadsoftware die sich im Installer befindet. Nun das Beispiel unter Linux mit dem Paket das die Programmdaten erhält. Auch hier wirst du nach Adminrechten gefragt, aber das macht nicht das das Paket, sondern die auf dem System bereits installierte Paketsoftware, die solche Pakete auswertet und installiert. Diese Paketsoftware installiert dann die Progarmmdateien dieser Software in eine Ordner, so dass Benutzer das neue Programm starten und ausführen können. Bis zu diesem Zeitpunkt war die Schadsoftware noch nicht aktiv. Erst wenn der Nutzer die Software benutzt, kann die Schadsoftware aktiv werden. Da der Nutzer aber keine Adminrechte hat, wird der Schaden auf die Daten des Nutzers begrenzt. Die Daten anderer Nutzer sind so nicht gefährdet und das System auch nicht. Das ändert sich erst, wenn der Admin das Programm mit Adminrechten starten würde, was man aber in der Regel nicht macht, zumal der Admin, wenn er nicht doof ist, sowieso nen eigenen Nutzeraccount mit einfachten Nutzerrechten hat. Bei SNAP & Co kommt noch hinzu, dass diese Art von Software ohnehin in einer Sandbox ausgeführt werden. Da hat hat die Schadsoftware dann erst recht kaum Möglichkeiten sich auszubreiten. > Beides muß aus vertrauenswürdigen Quellen stammen. Das sowieso, aber darum geht es in diesem Fall nicht, sondern darum, was passiert, wenn die Software nicht vertrauenswürdig ist. Also welchen Schaden sie anstellen könnte. > Mal davon abgesehen, daß durch das hineinziehen aller libs nur für ein > Programm solche SW gigantischen FP Speicher verbraucht. So etwas macht > man nur im Notfall. Klar, ich halte auch nicht viel von diesen SNAP und Flatpak Lösungen, aber zu den Installern die bei Windows der Normalfall sind, gibt es sicherheitstechnisch dann doch noch einmal einen ganz großen Unterschied. Siehe oben.
Nano schrieb: > Diese Paketsoftware installiert dann die Progarmmdateien dieser Software > in eine Ordner, so dass Benutzer das neue Programm starten und ausführen > können. > Bis zu diesem Zeitpunkt war die Schadsoftware noch nicht aktiv. Zumindest in debian gibt es in packeten diverse hook scripte, für vor/nach installation, vor/nach entfernen, etc.
Nano schrieb: > Da der Nutzer aber keine Adminrechte hat, wird der Schaden auf > die Daten des Nutzers begrenzt. Naja … auf den meisten (Einzel-/Arbeitsplatz-)Systemen sind die Nutzerdaten das, was wertvoll (und oft genug auch missbrauchbar) ist. Und Malware, welche das Gerät nur dem IoBotnetz hinzufügen, oder Spam versenden, oder sonstwas nach außen machen soll, was keine Sourceports <1024 erfordert, benötigt eh keine Adminrechte. Nano schrieb: > Bei SNAP & Co kommt noch hinzu, dass diese Art von Software ohnehin in > einer Sandbox ausgeführt werden. Das würde bedeuten, die Software könnte nicht auf das Verzeichnis des Nutzers zugreifen, also auch keine Daten drin ablegen? Das stelle ich mir umständlich vor, wenn jedes Programm z.B. sein eigenes Dokumentenverzeichnis haben soll.
Nano schrieb: > Erst wenn der Nutzer die Software benutzt, kann die Schadsoftware aktiv > werden. Da der Nutzer aber keine Adminrechte hat, wird der Schaden auf > die Daten des Nutzers begrenzt. > Die Daten anderer Nutzer sind so nicht gefährdet und das System auch > nicht. OK, das ist ein Argument wo ich Dir zustimme. DPA schrieb: > Zumindest in debian gibt es in packeten diverse hook scripte, für > vor/nach installation, vor/nach entfernen, etc. Außer bei diesem Problem hier. Aber es stimmt schon. Die Installation einer SW ist so immer noch sicherer als bei Win. Jack V. schrieb: > Das würde bedeuten, die Software könnte nicht auf das Verzeichnis des > Nutzers zugreifen, also auch keine Daten drin ablegen? Das stelle ich > mir umständlich vor, wenn jedes Programm z.B. sein eigenes > Dokumentenverzeichnis haben soll. Na ja, sagen wir es mal so: Wer Murks installiert, soll auch Murks bekommen.
Nochmal zum Punkt der Berechtigungen (und um auf die eine Frage weiter oben etwas einzugehen): wenn ich Malwareschreiberling wäre, wäre meine Zielgruppe wohl die Ubuntu-Welt und deren Ableger. Die sind im Anwenderbereich zahlenmäßig ausreichend stark vertreten, damit es sich lohnen könnte, und es ist durch deren kaputte sudo-Konfiguration recht einfach, Rootrechte zu erlangen.
Jack V. schrieb: > Die sind im > Anwenderbereich zahlenmäßig ausreichend stark vertreten, damit es sich > lohnen könnte, OK > und es ist durch deren kaputte sudo-Konfiguration recht > einfach, Rootrechte zu erlangen. Das magst Du mal näher erläutern.
Andreas B. schrieb: >> und es ist durch deren kaputte sudo-Konfiguration recht >> einfach, Rootrechte zu erlangen. > Das magst Du mal näher erläutern. Einfach nen "alias sudo='sudo evil.sh && sudo'" in die .bashrc eintragen, und warten, bis der User z.B. ein "sudo apt-get update" oder so macht. Oder noch besser, PATH in .profile, .bashrc, etc. anpassen, und nicht nur sudo, sondern auch gksudo und co. auf die weise überall erstmal ein böses Skript ausführen lassen.
Jack V. schrieb: > Nano schrieb: >> Da der Nutzer aber keine Adminrechte hat, wird der Schaden auf >> die Daten des Nutzers begrenzt. > > Naja … auf den meisten (Einzel-/Arbeitsplatz-)Systemen sind die > Nutzerdaten das, was wertvoll (und oft genug auch missbrauchbar) ist. https://xkcd.com/1200/
DPA schrieb: > Einfach nen "alias sudo='sudo evil.sh && sudo'" in die .bashrc > eintragen, und warten, bis der User z.B. ein "sudo apt-get update" oder > so macht. Das setzt aber alles voraus, Daß Du schon auf dem PC mit Userrechten Zugriff hast. Das würde so auf jedem System funktionieren wo dieser User Mitglied von sudoer ist. Sprich, bei jedem privaten System, wo der erste (oder einzige) Nutzer auch in sodoer ist. Hat mit Ubuntu also nicht viel zu tun, sondern mit der Existenz von sudo.
Andreas B. schrieb: > DPA schrieb: >> Einfach nen "alias sudo='sudo evil.sh && sudo'" in die .bashrc >> eintragen, und warten, bis der User z.B. ein "sudo apt-get update" oder >> so macht. > > Das setzt aber alles voraus, Daß Du schon auf dem PC mit Userrechten > Zugriff hast. Ja davon gehe ich aus, sonst kann man sudo ja gar nicht nutzen, und dann wäre auch eine "kaputte sudo-Konfiguration" egal. > Das würde so auf jedem System funktionieren wo dieser User Mitglied von > sudoer ist. Sprich, bei jedem privaten System, wo der erste (oder > einzige) Nutzer auch in sodoer ist. Nein. Lass mich dir erklären, was er mit der "kaputten sudo-Konfiguration" gemeint hat. In der Datei "/etc/sudoers" steht "%sudo ALL=(ALL:ALL) ALL". Also jeder in der grupe "sudo" kann mit einem Passwort jedes Kommando als Root ausführen. Das ist die problematische Konfiguration. > Hat mit Ubuntu also nicht viel zu tun, sondern mit der Existenz von > sudo. Nein, ohne diese Konfiguration wäre der Beispielangriff von oben nicht möglich. Genauer gesagt, ist der problematische Part, das jedes Kommando erlaubt wird. Auf meinem System erlaube ich nur "halt" und "reboot" ohne Parameter und ohne Passwort als Root Auszuführen. Das ist ein möglicher legitimer und sicherer use-case von sudo. Aber es ist schon so, dass sich die miss-Praxis schon auf den meisten Distros verbreitet hat.
DPA schrieb: > Nein. Lass mich dir erklären, was er mit der "kaputten > sudo-Konfiguration" gemeint hat. In der Datei "/etc/sudoers" steht > "%sudo ALL=(ALL:ALL) ALL". Also jeder in der grupe "sudo" kann mit > einem Passwort jedes Kommando als Root ausführen. Das ist die > problematische Konfiguration. OK, das ist natürlich ein Problem. Das läßt sich bei Ubuntu und Ablegern leider nicht ändern, weil alle graphischen Adminwerkzeuge mit sudo drangehen.
Danke, DPA. Andreas B. schrieb: > Das läßt sich bei Ubuntu und > Ablegern leider nicht ändern, weil alle graphischen Adminwerkzeuge mit > sudo drangehen. … und das ist eben einer meiner größeren Kritikpunkte an Ubuntu. Wenn’s eine bewusste, informierte Entscheidung des Users wäre, sein ›sudo‹ so verbogen haben zu wollen, fände ich das in Ordnung. Aber dass die User gar keine andere Möglichkeit haben, halte ich für problematisch. Unschön finde ich in dem Zusammenhang auch, dass mittlerweile selbst Debian auf die kaputte Konfiguration zurückfällt, wenn man während der Installation kein Root-Passwort vergibt. Aber hier hat man zumindest noch die Wahl. Es ist ja heutzutage tatsächlich so, dass nicht wenige User ›sudo‹ generell vor alles schreiben, was sie aus einer Shell heraus aufrufen, weil sie’s überall so lesen und es wohl für eine Art „führe aus: …“-Befehl zu halten scheinen :/
Jetzt wird es aber erst richtig lustig: Ich habe Mint 19.3 AM laufen. Beim upgrade von 19.2 auf 19.3 hatte er nach der Einrichtung des root PW gefragt (vorher gab es kein root user). So weit, so schön. Jetzt habe ich mal %sudo ALL=(ALL:ALL) ALL aus der sudoers mit visudo auskommentiert. Neu eingeloggt + nach sudo apt-get xxx erscheint die Meldung das dieser user apt-get nicht ausführen darf. Alles schön. Rufe ich aber jetzt die graphische Paketverwaltung auf, dann fragt er das user PW ab und macht ansonsten alles ungerührt, was er vorher via sudoers verboten bekommen hatte. Das ist wirklich der Hammer!
Andreas B. schrieb: > Rufe ich aber jetzt die graphische Paketverwaltung auf, dann fragt er > das user PW ab und macht ansonsten alles ungerührt, was er vorher via > sudoers verboten bekommen hatte. Das ist wirklich der Hammer! Weil das nicht sudo verwendet, sondern polkit.
DPA schrieb:
Dein Beispiel leuchtet ein.
Wie führst du allerdings grafische Anwendungen aus, die root Rechte
benötigen?
Loggst du dich dazu als root in eine Desktop Oberfläche ein und bleibst
du in der Desktop Oberläche des Nutzers und verwendest in einem Terminal
dann dafür so Lösungen wie su?
Dass das X Window System mangels Vergleichbares wie UAC selbst nicht so
sicher ist, lasse ich mal für die Frage dahin gestellt.
Jack V. schrieb: > Aber dass die User > gar keine andere Möglichkeit haben, halte ich für problematisch. Naja, man kann es wieder abschalten. Genauso wie man es bei Debian einschalten kann. Dass der Nutzer nicht vorher gefragt wird, da gebe ich dir natürlich recht. Allerdings fehlt es hier ohnehin einer ordentlichen Lösung, wie man sie bspw. mit Windows mit UAC hat. Mit Wayland soll das zum Glück ja besser werden.
Nano schrieb: > Wie führst du allerdings grafische Anwendungen aus, die root Rechte > benötigen? Garnicht.
DPA schrieb: > Nano schrieb: >> Wie führst du allerdings grafische Anwendungen aus, die root Rechte >> benötigen? > > Garnicht. Das ist keine sinnvolle Antwort. Um mal ein Beispiel zu nennen. Der Elster Authenicator verlangt bei der Installation eine GUI und root Rechte, falls man ihn für mehrere Benutzer nach /usr/local/ installieren will. Eine Installation via root ohne GUI ist nicht vorgesehen.
Solche Installer verwende ich in der regel nicht. Und falls doch hab ich mittel und wege, so zeug auch ohne Root zum laufen zu bringen. Ich bootstrappe manchmal ganze Systeme ohne echtes Root rechte, da dürfte ein progrämchen für mich kein Problem sein. Im einfachsten fall reicht unshare um fake root rechte zu erlangen. Falls ich mehr uids brauche hab ich mein uexec tool (https://github.com/Daniel-Abrecht/usernsexec (erfordert sysctl kernel.unprivileged_userns_clone=1)). Und wenn ich aus Berechtigungsgründe noch Verzeichnisse verbiegen muss, kann ich mit "unshare -m" und nem shellscript ein paar bind mounts und andere spielereien machen, so wie hier: https://github.com/Daniel-Abrecht/librem5-image-builder/blob/master/script/chroot_qemu_static.sh https://github.com/Daniel-Abrecht/librem5-image-builder/blob/master/script/chroot_qemu_static-sub1.sh Am schluss eventuell die Dateien noch an den richtigen Ort kopieren, oder ein wrapper script zum starten machen, oder sonst was. Für normalsterbliche ist eventuell ein Docker container die einfachere Alternative.
Nano schrieb: > Der Elster Authenicator verlangt bei der Installation eine GUI und root > Rechte, falls man ihn für mehrere Benutzer nach /usr/local/ installieren > will. > > Eine Installation via root ohne GUI ist nicht vorgesehen. Das wäre einen Bugreport wert. Jemand, der diese Software nutzt, sollte sich darum kümmern, und dem Hersteller mal Bescheid sagen.
Jack V. schrieb: > Das wäre einen Bugreport wert. Jemand, der diese Software nutzt, sollte > sich darum kümmern, und dem Hersteller mal Bescheid sagen. Das könnte man mit gtk-sudo regeln. Ich denke gerade darüber nach, dieses polkit aus meinem System zu entfernen. Irgendwie gefällt mir das überhaupt nicht. Spontan fallen mit nur synaptic und Rechteverwaltung ein, wofür man root in der GUI braucht. Das geht aber auch in der Konsole.
Axel S. schrieb: > Bei VW verlängert sich bspw. die > Mobilitätsgarantie, wenn du den Service in einer autorisierten Werkstatt > machen läßt. Alternativ kannst du für weniger Geld eine freie Werkstatt > beauftragen, verlierst dabei aber die Garantie. unhaltbares Märchen.Lug nicht: BGH Urteil: Kein Garantieverfall, wenn das Auto in freier Werkstatt gewartet wird
Jack V. schrieb: > Nano schrieb: >> Der Elster Authenicator verlangt bei der Installation eine GUI und root >> Rechte, falls man ihn für mehrere Benutzer nach /usr/local/ installieren >> will. >> >> Eine Installation via root ohne GUI ist nicht vorgesehen. > > > Das wäre einen Bugreport wert. Jemand, der diese Software nutzt, sollte > sich darum kümmern, und dem Hersteller mal Bescheid sagen. Die geben nicht einmal für Debian Support, sondern nur für Ubuntu. Den Support hatte ich schon angeschrieben, mit der Meldung, dass sie nur Ubuntu supporten würde. Auf der Elster Webseite heißt es dagegen erst einmal nur, dass sie Linux unterstützen würden. Das mit dem Ubuntu Zwang steht irgendwo in der FAQ. Jetzt läuft der Elster Authenticater auf einem Ubuntu Gastsystem in einer VM auf einem Debian Host. Der USB Dongle muss natürlich an die VM durchgereicht werden.
Osgalomenix schrieb: > Axel S. schrieb: >> Bei VW verlängert sich bspw. die >> Mobilitätsgarantie, wenn du den Service in einer autorisierten Werkstatt >> machen läßt. Alternativ kannst du für weniger Geld eine freie Werkstatt >> beauftragen, verlierst dabei aber die Garantie. > > unhaltbares Märchen.Lug nicht: BGH Urteil: Kein Garantieverfall, wenn > das Auto in freier Werkstatt gewartet wird Lern lesen, du Kasper! Ich schrieb nicht "Garantieverfall", sondern "keine Verlängerung". Äpfel und Birnen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.