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!
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.
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?
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.
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.
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.shhttps://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.
