Forum: PC-Programmierung Warum $PATH ohne /sbin bei Debian?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bauform B. (bauformb)


Lesenswert?

hallo Unix-Historiker,

nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin 
und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst 
neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch 
nicht?

Diverse Befehle wie mount waren schon immer auch für User nützlich. 
Jetzt will man man /sbin und /bin zusammenlegen, also /sbin abschaffen. 
Andererseits ist noch in 2019 rdate von /bin nach /sbin gewandert!?

https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

https://lists.debian.org/debian-devel/2024/02/msg00298.html

Leider hilft das dem PATH nicht, im Gegenteil. Bei Fedora könnte alles 
in /bin landen, aber bei Debian in /usr/bin und als Sahnehäubchen möchte 
man einzelne Programme nach /libexec oder /usr/libexec oder sogar /lib 
verschieben.

: Gesperrt durch Moderator
von Jack V. (jackv)


Lesenswert?

Bauform B. schrieb:
> nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin
> und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst
> neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch
> nicht?

Weil „Utilities used for system administration (and other root-only 
commands) are stored in /sbin and /usr/sbin” (FHS). Da man 
klassischerweise administrative Aufgaben als Root durchführt, ist damit 
auch nichts verkehrt – nur, wenn man beispielsweise die kaputte 
sudo-Konfiguration der Buntus nutzt, die sich leider etabliert hat 
(weil: „Bequemlichkeit first, Sicherheit second“, oder so …), muss man 
halt dran denken.

Bei anderen Distributionen ist /usr/sbin auch heute in der Regel nicht 
in PATH eines ordinären Users, sondern /sbin und Co. sind Symlinks auf 
/usr/bin.

: Bearbeitet durch User
von Rolf (rolf22)


Lesenswert?

Bauform B. schrieb:
> nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin
> und /usr/sbin nicht starten (bzw. nur umständlich)?

Ich arbeite heute nur auf dem Raspi mit Linux, kenne aber den Urvater 
Unix noch aus der Zeit, als Linus noch in den Kindergarten ging.

Unix war ursprünglich ein reines Server/Client-OS für mehrere Nutzer. 
Der teure Rechner stand in einem eigenen Raum, da durfte nur ein Admin 
rein. Die Nutzer saßen irgendwo anders an einfachen Text-Terminals. Da 
durfte natürlich kein Nutzer alle Systembefehle nutzen, z. B. beliebige 
Datenträger mounten, Programme oder Updates einspielen oder gar den 
Rechner herunterfahren. Die Executables für den Admin standen deshalb 
zur Klarheit separat in /sbin. Ist eine historische Altlast.

> warum bei Debian immer noch nicht?

Die Debian-Philosophie ist es, möglichst wenig **unnötig** zu ändern. 
Debian will vermeiden, dass man oft frickeln muss, auch wenn man 
eigentlich keine neuen Funktionen braucht/will. Man soll UNTER dem OS 
arbeiten können, ohne AN dem OS frickeln zu müssen. Die Kehrseite ist, 
dass sich manche Programme nicht installieren lassen, weil sie Libs 
brauchen, die Debian (noch) nicht kennt.

> Diverse Befehle wie mount waren schon immer auch für User nützlich.

Unter Client/Server-Unix durfte man natürlich nicht einfach irgendwelche 
physischen Datenträger mounten: Man war ja nicht alleine am Rechner.
Ich erinnere mich am einen Bürorechner von 1980, da musste man sich als 
root anmelden, nur um eine Diskette mounten zu können. Praktisch musste 
deshalb jeder das root-Passwort kennen, also hieß es root. :-)
War ziemlich umständlich damals, weil ja jeder seine eigene Arbeit auf 
Disketten haben wollte, damit er sie sicher in den Schrank legen konnte.

Heute arbeiten die meisten von uns nicht unter einem 
Server/Client-System, sondern unter einem Desktop-System, wo sie ihr 
eigener Admin sind. Dafür ist sudo ganz praktisch, es gab das aber auch 
schon unter späteren Versionen von Unix.

> Jetzt will man man /sbin und /bin zusammenlegen, also /sbin abschaffen.
> Andererseits ist noch in 2019 rdate von /bin nach /sbin gewandert!?

> Bei Fedora könnte alles in /bin landen, aber bei Debian in /usr/bin und
> als Sahnehäubchen möchte man einzelne Programme nach /libexec oder
> /usr/libexec oder sogar /lib verschieben.

Ja, und wenn man Shell-Scripts hat, laufen die wegen so was dann 
plötzlich nicht mehr und das Frickeln geht los.
Du weißt ja sicher, was die Hardcore-Linuxer dir dann sagen: "Linux hat 
da keine Schuld, das ist ja nur der Kernel. Und es ist doch supergut, 
dass sich jeder eine für ihn passende Distri auswählen kann."

: Bearbeitet durch User
von Monk (roehrmond)


Lesenswert?

Rolf schrieb:
> Die Kehrseite ist, dass sich manche Programme nicht installieren lassen,
> weil sie Libs brauchen, die Debian (noch) nicht kennt.

Ja. In solchen Fällen habe ich allerdings keine Hemmungen, die fehlenden 
Pakete von Ubuntu zu "borgen". Das hat bisher immer geklappt.

Trotz gelengentlicher Trickserei dieser Art bevorzuge ich Debian wegen 
seiner genannten Stabilität. Es soll zuverlässig laufen ohne alle paar 
Wochen mit neuen Änderungen oder neuen Bugs zu überraschen.

Wenn ich von einzelnen Programmen eine sehr aktuelle Version haben will, 
kann ich das ja immer noch separat installieren. Als ehemaliger Windows 
User bin ich mit der Methode aufgewachsen.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Jack V. schrieb:
> Bei anderen Distributionen ist /usr/sbin auch heute in der Regel nicht
> in PATH eines ordinären Users, sondern /sbin und Co. sind Symlinks auf
> /usr/bin.

Dann gibt es ja praktisch kein /sbin mehr, also reicht auch ein 
PATH="/usr/bin"; in Zukunft sieht es wohl so aus.

Rolf schrieb:
> Der teure Rechner stand in einem eigenen Raum, da durfte nur ein Admin
> rein. Die Nutzer saßen irgendwo anders an einfachen Text-Terminals. Da
> durfte natürlich kein Nutzer alle Systembefehle nutzen, z. B. beliebige
> Datenträger mounten, Programme oder Updates einspielen oder gar den
> Rechner herunterfahren. Die Executables für den Admin standen deshalb
> zur Klarheit separat in /sbin. Ist eine historische Altlast.

Für die Trennung von /bin und /usr/bin gibt es ja eine vernünftige 
Erklärung, aber die passt nicht für /bin vs /sbin. Bleibt also nur 
Tradition, das ist auch ok. Ich kenne auch PATH nur ohne /sbin, erst, 
als ich jetzt wieder rdate gebraucht hatte, ist es mir aufgefallen. Vor 
allem, weil das das Gegenteil von unified /bin ist.

> Ich erinnere mich am einen Bürorechner von 1980, da musste man sich als
> root anmelden, nur um eine Diskette mounten zu können. Praktisch musste
> deshalb jeder das root-Passwort kennen, also hieß es root. :-)

Ich glaube, mounten ging hier schon mit der mount option "users" und zum 
Runterfahren gab es den User halt, Passwort halt ;)

von Rolf (rolf22)


Lesenswert?

Steve van de Grens schrieb:
> Wenn ich von einzelnen Programmen eine sehr aktuelle Version haben will,
> kann ich das ja immer noch separat installieren.

Äh, was genau meinst du mit "separat"?

von Monk (roehrmond)


Lesenswert?

Rolf schrieb:
> Äh, was genau meinst du mit "separat"?

Von der Homepage des Autors herunter laden, anstatt es aus der Linux 
Distribution zu nehmen.

von Jack V. (jackv)


Lesenswert?

Bauform B. schrieb:
> Für die Trennung von /bin und /usr/bin gibt es ja eine vernünftige
> Erklärung, aber die passt nicht für /bin vs /sbin.

In meinen Augen ist die Trennung zwischen */usr* und */* (Edit: die 
Textformatierung in diesem Forum könnte ruhig auch mal auf den Stand 
dieses Jahrtausends gebracht werden, ohne die * werden die Slashes 
gefressen …) heute eher weniger vernünftig erklärbar, als eine Trennung 
der Werkzeuge zur Systemadministration und der Anwendersoftware. Ich 
kenne keinen, der heute /usr heute noch in einem eigenen Dateisystem 
hat, aber dass ein User mangels Rechten nichts mit beispielsweise 
adduser anfangen kann, und das daher auch nicht in seinem Suchpfad 
braucht, ist im Grunde auch heute noch der Fall.

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Steve van de Grens schrieb:
> Von der Homepage des Autors herunter laden, anstatt es aus der Linux
> Distribution zu nehmen.

Und dann? Das Herunterladen ist hier nicht so spannend, sondern das 
danach, Stichwort "Linux-Dreisatz".
Bei Skyrim-Mods ist das ja kein Ding, die haben ihre eigene Logistik. 
Und ein neueres Programm? Kann man bei Wine auch nehmen, heißt dann aber 
passend "testing" und kann man über den üblichen Weg installieren.

von Alexander S. (alesi)


Lesenswert?

Jack V. schrieb:
> (Edit: die Textformatierung in diesem Forum könnte ruhig auch mal auf den
> Stand dieses Jahrtausends gebracht werden, ohne die * werden die Slashes
> gefressen …)

https://www.mikrocontroller.net/articles/Formatierung_im_Forum

von Jack V. (jackv)


Lesenswert?

Alexander S. schrieb:
> https://www.mikrocontroller.net/articles/Formatierung_im_Forum

Ist schon klar. Versuch mal, die obenstehende Darstellung in meinem 
Beitrag ohne die * zu schreiben – dann verstehst du sicher, was ich 
meine.

: Bearbeitet durch User
von Klar P. (Gast)


Lesenswert?

> nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin
> und /usr/sbin nicht starten (bzw. nur umständlich)? Warum ist erst
> neuerdings™ /sbin in $PATH enthalten? Und warum bei Debian immer noch
> nicht?

Weil das ein essentielles Sicherheitsfeature/Zugriffsschutz in 
Multi-User/Multitask systemen ist.

https://de.wikipedia.org/wiki/Mehrbenutzersystem#Rechtemanagement

/sbin ist halt das Verzeichniss für systemprogramme wie "su" oder 
"shutdown"
mit denen ein "normaler User. nur Unsinn anstellt.

von Jack V. (jackv)


Lesenswert?

Klar P. schrieb:
> /sbin ist halt das Verzeichniss für systemprogramme wie "su"

Nun ja – su in /sbin wäre ziemlich dämlich, oder?

Abgesehen davon kann ein User auch unter Debian jederzeit Programme 
aus /sbin und /usr/sbin zu starten versuchen – er muss halt den Pfad mit 
angeben. Eine Sicherheitsfunktion war das nie – dazu ist die 
Rechteverwaltung da. Es war nur geschickt, als Bytes noch was wert waren 
und Festplattenzugriffe für spürbare Pausen gesorgt haben. Ist heute 
nicht mehr so wichtig.

von Klar P. (Gast)


Lesenswert?

Jack V. schrieb:
> Klar P. schrieb:
>> /sbin ist halt das Verzeichniss für systemprogramme wie "su"
>
> Nun ja – su in /sbin wäre ziemlich dämlich, oder?

Stimmt, oder? Aber es hat doch das SUID-bit gesetzt oder?
Und man kann Programme unter Angabe des vollständigen pathes starten 
/sbin/su sollte doch kein Problen darstellen, wenn man nicht gerade ein 
Tastaturspastiker ist.

https://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap18A-004.htm#:~:text=SUID%20(Set%20User%20ID)%20und,die%20GID%20der%20Besitzergruppe%20erh%C3%A4lt
https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#/sbin_%E2%80%93_wichtige_Systembefehle

> Eine Sicherheitsfunktion war das nie

Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man 
nicht in den $PATH packen sollte.

von Jack V. (jackv)


Lesenswert?

Klar P. schrieb:
> Stimmt, oder?

Ich wollte darauf hinaus, dass auch unter Debian su unter /usr/bin zu 
finden ist – schließlich will man, dass der normale User das ohne 
Hürden nutzen kann.

Klar P. schrieb:
> Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man
> nicht in den $PATH packen sollte.

Du merkst selbst, wie du dir widersprichst, oder?

Klar P. schrieb:
> Und man kann Programme unter Angabe des vollständigen pathes starten

$PATH beinhaltet den Suchpfad. Das ist für die Bequemlichkeit, und hat 
mit Sicherheit nichts zu tun.

: Bearbeitet durch User
von Klar P. (Gast)


Lesenswert?

> Ich wollte darauf hinaus, dass auch unter Debian su unter /usr/bin zu
> finden ist – schließlich will man, dass der normale User das ohne
> Hürden nutzen kann.

manchmal deucht mir man will dem unterprivilegierten user su mit 
sudo austreiben  ...
https://www.opensuse-forum.de/thread/40397-su-oder-sudo-und-der-ganze-shell-und-login-wirrwarr/

von Klar P. (Gast)


Lesenswert?

>> Also ich kenn da einige Sicherheitsregeln, die explizit angeben, was man
>> nicht in den $PATH packen sollte.
>
> Du merkst selbst, wie du dir widersprichst, oder?
Da ist kein Widerspruch, du siehst (noch?) nicht klar.

>  Das ist für die Bequemlichkeit, und hat
> mit Sicherheit nichts zu tun.
Bequemlichkeit ist der Tod der Sicherheitsregeln.
https://tldp.org/HOWTO/Path-12.html

von Jack V. (jackv)


Lesenswert?

Klar P. schrieb:
> manchmal deucht mir man will dem user su mit sudo austreiben

Mir deucht, du hast nicht den Schimmer einer Ahnung von Linux in der 
Praxis – sonst hättest du kurz nachgeschaut, bevor du gepostet hast:

Ausgabe von ›which su‹ unter
Arch: /usr/bin/su
Buster: /usr/bin/su
Bookworm: /usr/bin/su
RaspberryPi OS: /usr/bin/su
grml: /usr/bin/su

… mehr hab ich nicht hier. Und nun erzähl’ mir nochmal, dass ›su‹ als 
Systemprogramm unter /sbin liegen würde.

von Klar P. (Gast)


Lesenswert?

> … Und nun erzähl’ mir nochmal, dass ›su‹ als
> Systemprogramm unter /sbin liegen würde.

Nö, warum Rücktritt vom Rücktritt? - gehts dir dann besser ??
Ist Dein Wohlbefinden für irgendjemand hier relevant?

von Jack V. (jackv)


Lesenswert?

Klar P. schrieb:
> Ist Dein Wohlbefinden für irgendjemand hier relevant?

Ah, Argumente sind aus – geht auf die persönliche Ebene. So, wie ich 
dich kenne, bekommst du die Kurve zurück zum Thema eh nicht mehr – viel 
Spaß also noch o/

von Klar P. (Gast)


Lesenswert?

Jack V. schrieb:
> Klar P. schrieb:
>> Ist Dein Wohlbefinden für irgendjemand hier relevant?
>
> Ah, Argumente sind aus – geht auf die persönliche Ebene. So, wie ich
> dich kenne, bekommst du die Kurve zurück zum Thema eh nicht mehr – viel
> Spaß also noch o/

Danke, gleichfalls /oo

von Norbert (der_norbert)


Lesenswert?

Klar P. schrieb:
> Bequemlichkeit ist der Tod der Sicherheitsregeln

Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen,
der befindet sich auf einem Irrpfad.

Die Aufteilung der Verzeichnisse geht zurück in eine Zeit, als die 
Dinger noch auf separaten Platten lagen und entsprechend eingebunden 
wurden. Damit einhergehend hat man dann auch direkt eine Unterscheidung 
getroffen, welche Programme (im Allgemeinen) von wem genutzt werden.

Beim neuesten Debian wird man zum Beispiel feststellen, das einige 
Verzeichnisse nunmehr als Symlinks zu anderen Verzeichnissen darstellt 
werden.
Sanfter Übergang, usw.

von Jack V. (jackv)


Lesenswert?

Norbert schrieb:
> Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen,
> der befindet sich auf einem Irrpfad.

Wäre das Äquivalent zum DNS-Stoppschild, das gewisse Politisierende 
damals™ etablieren wollten. Da haben wir auch sehr gelacht. Bzw. hätten, 
weil’s eigentlich ziemlich traurig war.

von Klar P. (Gast)


Lesenswert?

Norbert schrieb:
> Klar P. schrieb:
>> Bequemlichkeit ist der Tod der Sicherheitsregeln
>
> Wer glaubt die Sicherheit mit einem Suchpfad zu erhöhen,
> der befindet sich auf einem Irrpfad.

Die Argumentation geht hier  eigentlich in die entgegensetzte Richtung, 
mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit 
erniedrigen resp. ein security risk schaffen ...

von Norbert (der_norbert)


Lesenswert?

Klar P. schrieb:
> Die Argumentation geht hier  eigentlich in die entgegensetzte Richtung,
> mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit
> erniedrigen resp. ein security risk schaffen ...

Ich sehe keine Argumentation.

Ein Programm welches Dinge tun möchte für die der Benutzer sowieso keine 
Rechte hat, wird ganz simpel rein gar nichts bewerkstelligen.
Der Benutzer darf gerne zB. fdisk und Konsorten aufrufen (oder es 
versuchen), da passiert mal gar nichts.
1
~$ /sbin/fdisk -l
2
fdisk: cannot open /dev/sdd: Permission denied
3
fdisk: cannot open /dev/sda: Permission denied
4
fdisk: cannot open /dev/sdc: Permission denied
5
fdisk: cannot open /dev/sdb: Permission denied

Warum sollte das die Sicherheit verringern?

von Klar P. (Gast)


Lesenswert?

Norbert schrieb:
> Klar P. schrieb:
>> Die Argumentation geht hier  eigentlich in die entgegensetzte Richtung,
>> mit einem (dumm/bequem gesetzten) Suchpfad kann man die Sicherheit
>> erniedrigen resp. ein security risk schaffen ...
>
> Ich sehe keine Argumentation.

Da ist aber ein link, den man folgen könnte ...


> Warum sollte das die Sicherheit verringern?
Denk mal vom "user" weg, denk an "root". Und daran, das viele security 
risks eben deshalb risks sind, weil sich eben der Unterprivilegierte 
Privilegien verschaffen könnte indem er root etwas "unterschiebt".

von Norbert (der_norbert)


Lesenswert?

Klar P. schrieb:
> Da ist aber ein link, den man folgen sollte.

Wenn du den tldp meinst, da steht auch nichts, aber auch wirklich gar 
nichts, was nicht schon seit einem halben Jahrhundert bekannt ist.

Und wenn root blöde genug ist auf ungesicherte Verzeichnisse im Suchpfad 
zuerst zuzugreifen, das sagt mehr über den Menschen als über die 
Architektur aus.

von Klar P. (Gast)


Lesenswert?

Norbert schrieb:
> Klar P. schrieb:
>> Da ist aber ein link, den man folgen sollte.
>
> Wenn du den tldp meinst, da steht auch nichts, aber auch wirklich gar
> nichts, was nicht schon seit einem halben Jahrhundert bekannt ist.

Ja eben, "Bequemlichkeit ist der Tod der Sicherheitsregeln", sollte 
sogar noch länger bekannt sein als 50 Jahre.

> Und wenn root blöde genug ist auf ungesicherte Verzeichnisse im Suchpfad
> zuerst zuzugreifen, das sagt mehr über den Menschen als über die
> Architektur aus.

Naja Architekturen kann man anpassen, bei Menschen muss man mit deren 
Irrungen leben oder eben die Umgebung möglichst foolproof gestalten.

von Norbert (der_norbert)


Lesenswert?

Klar P. schrieb:
> Ja eben, "Bequemlichkeit ist der Tod der Sicherheitsregeln", sollte
> sogar noch länger bekannt sein als 50 Jahre.

Bevor du noch weiter um den heißen Brei herum redest, auf welchem System 
wird per default so etwas Blödes eingerichtet?

Richtig, auf keinem.

Also müsste es root nachträglich machen.
Und wenn jemand gleichzeitig root und blöd ist (die denkbar ungünstigste 
Konstellation), dann helfen auf keine Pfadeinschränkungen.

von Klar P. (Gast)


Lesenswert?

> Bevor du noch weiter um den heißen Brei herum redest, auf welchem System
> wird per default so etwas Blödes eingerichtet?
>
> Richtig, auf keinem.

Mutig so eine Aussage über geschätzt eine Billiarde installierte Systeme


> Also müsste es root nachträglich machen.
> Und wenn jemand gleichzeitig root und blöd ist (die denkbar ungünstigste
> Konstellation), dann helfen auf keine Pfadeinschränkungen.

Faule Ausrede, Menschen neigen nun mal es sich bequem zu machen. Und 
seit der Einführung von Suse und breiten Einsatz von Linux in der 
Ausbildung hat man ohnehin die Kontrolle über die Befähigung der 
(Hobby-)Administratoren verloren. Aber deshalb gleich alle 
Sicherheitshinweise und "dos and don'ts" zu ignorieren ist sicher keine 
gute Idee..

von Norbert (der_norbert)


Lesenswert?

Klar P. schrieb:
> Mutig so eine Aussage über geschätzt eine Billiarde installierte Systeme

Ernsthaft?  Das ist deine Aussage?
Ich hatte per default geschrieben. Ohne nachträglichen Idioteneingriff!

Aber wenn du das wirklich glaubst, dann nenn' eines.

Nee, lass es, ich bin raus hier. Hat keinen Zweck.

von Klar P. (Gast)


Lesenswert?

> Nee, lass es, ich bin raus hier. Hat keinen Zweck.

Für diese weise Einsicht gibt's, obwohl sie reichlich spät kommt, ein: 
'+1'.

von Jack V. (jackv)


Lesenswert?

Es trollt also absichtlich? Dann ergibt der Verlauf in der Tat Sinn. 
Schade.

von Ein T. (ein_typ)


Lesenswert?

Jack V. schrieb:
> auch nichts verkehrt – nur, wenn man beispielsweise die kaputte
> sudo-Konfiguration der Buntus nutzt, die sich leider etabliert hat

An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher.

von Ein T. (ein_typ)


Lesenswert?

Rolf schrieb:
> Unix war ursprünglich ein reines Server/Client-OS für mehrere Nutzer.

Zudem waren Festplatten eher klein und Sysops hatten schon damals eine 
Tendenz zur Zentralisierung, und deswegen wurde die /usr-Hierarchie 
mitunter von einem zentralen NFS-Host gemountet, und die installierte 
Software wurde dort zentral gepflegt. Trotzdem mußten die Systeme 
natürlich gewartet, und zudem natürlich /usr gemountet werden können, 
deswegen lagen bestimmte Binaries für normale Benutzer in /bin und für 
den Admin zusätzlich weitere in /sbin. Damit ließen sich viele Arbeiten 
auch im Singleuser-Modus ohne Netzwerk, mithin also ohne gemountetes 
usr-Verzeichnis erledigen.

Bei der Teilung von /bin und /sbin ging es auch um die 
Autokomplettierung, die verschiedene Shells (die Bash mit der Tab-Taste) 
anbieten. Früher haben Shells -- Festplatten waren nicht nur klein, 
sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen 
und im Speicher gecached. Durch die Trennung von Benutzer- und 
Admin-Kommandos konnte der Speicher für die Benutzer kleiner und die 
Startup-Zeit der Shell reduziert werden, denn auch der Arbeitsspeicher 
und die CPU-Leistung waren damals klein und teuer. Wenn man damals neue 
Programme in seinem $PATH installiert hatte, mußte man in der Z-Shell 
das Builtin rehash und in der Bash den Befehl "hash -r" aufrufen. Heute 
ist das nicht mehr nötig und die Bash liest die Liste der verfügbaren 
Binaries jedes Mal neu, wenn die Autokomplettierung aufgerufen wird.

von Jack V. (jackv)


Lesenswert?

Ein T. schrieb:
> An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher.

Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf 
alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, 
ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann? Gerade 
in Hinsicht auf die Hauptzielgruppe der Buntus, die gerne mal unkritisch 
irgendwelchen Kram aus PPAs holt, oder ebensogerne mal komplette 
Eingabezeilen mangels Verständnis ohne weitere Prüfung in die 
Eingabezeile pastet und ausführt? Ich find’s schon ein bisschen 
fragwürdig.

Versteh’s nicht falsch – ich mag sudo. Bei mir kann damit ein gegebener 
User einige sehr genau definierte Sachen machen. Das ist, wie’s 
ursprünglich auch gedacht war, wenn man der Programmbeschreibung glauben 
möchte. Entsprechend empfinde ich die Konfiguration der Buntus als … 
fragwürdig.

von Ein T. (ein_typ)


Lesenswert?

Rolf schrieb:
> Ja, und wenn man Shell-Scripts hat, laufen die wegen so was dann
> plötzlich nicht mehr und das Frickeln geht los.

Nur wenn man so dämlich war, sein System jenseits aller Standards 
komplett zu verbasteln, aber ist man ohnehin nicht mehr zu retten.

Denn solange */bin* ein Symlink auf */usr/bin*, */lib* einer auf 
*/usr/lib* ist und so weiter, ist es völlig egal, ob Du */bin/ls* oder 
*/usr/bin/ls* aufrufst: es wird automatisch das richtige Executable 
gestartet.

Vielleicht möchtest Du vor dem Verfassen von Beiträgen in diesem Forum 
etwas mehr über die inhaltliche Qualität Deines Beitrags nachdenken 
statt darüber, wie Du möglichst oft das Wort "Frickeln" darin 
unterbringen kannst.

von (prx) A. K. (prx)


Lesenswert?

Ein T. schrieb:
> beim Startup die verfügbaren Binaries gelesen
> und im Speicher gecached.

Deren Liste, nicht die Binaries.

von Foobar (asdfasd)


Lesenswert?

rolf schrieb:
> Unix war ursprünglich [...]. Die Executables für den Admin
> standen deshalb zur Klarheit separat in /sbin.

In /etc.  Das waren hauptsächlich Sachen zum Booten des Systems (inkl 
netwerk daemons).  Ein ziemliches Chaos von Configfiles und Executables 
- nix von "Klarheit".  /sbin haben ich, iirc, erstmalig bei Linux 
gesehen.  Kann aber sein, dass es das bei BSD schon früher gab.

Aus einem alten /etc/default/login:
1
...
2
PATH=:/usr/local/bin:/bin:/usr/bin:/usr/games
3
SUPATH=/etc:/usr/local/bin:/bin:/usr/bin:/usr/games
4
...

von Foobar (asdfasd)


Lesenswert?

Ein T schrieb:
> Früher haben Shells -- Festplatten waren nicht nur klein,
> sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen
> und im Speicher gecached.

Das wäre mir neu.  Irgendwelche Linux-Distries hatten sowas mal 
ausprobiert (beim Booten den Systemcache mit häufig benutzten Dateien 
seeden).  Das Shell hat nur einen Hash <kommandoname> -> <pfad> (see 
'help hash').

von Klar P. (Gast)


Angehängte Dateien:

Lesenswert?

>> Früher haben Shells -- Festplatten waren nicht nur klein,
>> sondern auch langsam -- beim Startup die verfügbaren Binaries gelesen
>> und im Speicher gecached.

> Das wäre mir neu.  Irgendwelche Linux-Distries hatten sowas mal

rehash ist älter als Linux. Linux kam erst mit dem 386 auf, im 
Ingenieurwesen liefen da bereits seit den Achtzigern Unix-Derivate auf 
Sun/Sparc-Kisten und ähnlichem.
Mit Slackware brach Linux 1993/94 langsam in die Studenten und 
Script-Kiddies-Szene ein. Viele kopierten sich die per ftp gezogenen 
(Floppy-)Disc-images
mit den mtools auf bspw eine DECstation in der Fakultät für den privaten 
PC-Gebrauch. Mit den Suse-CD-Images wurde das Ganze dann bequemer.

https://de.wikipedia.org/wiki/DECstation
https://www.unix.com/man-page/plan9/1/rehash/
https://en.wikipedia.org/wiki/Sun-1

Anbei die Erklärungen aus "Unix Power Tools" aus dem O'Reilly-Verlag 
dazu

von Foobar (asdfasd)


Lesenswert?

> rehash ist älter als Linux

Hab ich was anderes behauptet?

Es ging um:
> Früher haben Shells [...] beim Startup die verfügbaren Binaries gelesen
> und im Speicher gecached.

Und das haben sie nie gemacht.  Sie haben nur die Pfade von Binaries 
gecached.  Und auch nicht alle beim Startup, sondern einzeln, beim 
ersten mal benutzen.  Die darauf folgende Argumentation ergibt damit 
keinen Sinn.

Das was er beschreibt (cachen von Binaries) haben, wie gesagt, einige 
Linux-Distris mal ausprobiert (eine Liste von Dateien einmal während des 
Bootens lesen, damit sie im Cache sind (Ziel war iirc "Booten in <10s"). 
Filesystem sogar so optimiert, dass diese Dateien alle nah beieinander 
lagen, damit nicht groß geseekt werden muß.).  Hat aber nicht viel 
gebracht.

von Ein T. (ein_typ)


Lesenswert?

(prx) A. K. schrieb:
> Ein T. schrieb:
>> beim Startup die verfügbaren Binaries gelesen
>> und im Speicher gecached.
>
> Deren Liste, nicht die Binaries.

Natürlich. Man hätte zwar aus dem Kontext darauf kommen können, aber das 
hatte ich ungenau ausgedrückt. Danke für die Verdeutlichung. :-)

von Ein T. (ein_typ)


Lesenswert?

Foobar schrieb:
> /sbin haben ich, iirc, erstmalig bei Linux gesehen.

Hatte Solaris IIRC ab Solaris 7, das muß so etwa 98 oder 99 gewesen 
sein.

von Daniel A. (daniel-a)


Lesenswert?

Ich finde das mit /sbin eher nervig. Manchmal verwende ich die Binaries 
da drin nämlich auch als nicht-root, und dann muss ich den PATH anpassen 
oder den vollen Pfad angeben...

Als Beispiele `/sbin/ifconfig` zeigt auch ohne root die Infos an.
Die diversen mkfs.* Programme (z.B. mkfs.ext4), funktionieren auch bei 
normalen Dateien und Fuse Device Files. Genauso auch fdisk / sfdisk.
pivot_root kann man auch zusammen mit unshare / user namespaces 
verwenden.
etc.

PS: Mir gefällt der Symlink nonsens aber auch nicht besonders. Statt 
/bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen. Die 
Symlink betrachte ich als üblen Workaround.
Ok, dann hätte man mit `#!/bin/sh` usw. Probleme. Das ist aber auch 
irgendwie sowieso Mist. Man sollte mal einführen, dass `#!sh` wie 
`#!/usr/bin/env sh` funktioniert, oder irgend was in die Richtung. Aber 
irgendwie tun immer alle so, als könne man solche Altlasten nicht mehr 
ändern.

: Bearbeitet durch User
von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Man sollte bedenken dass an Unix und Linux ständig gebastelt wurde. Ein 
vereinfachtes Bild findet man zum Beispiel in der Wikipedia 
https://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Unix_history-simple.svg/1280px-Unix_history-simple.svg.png

Und jeder hat für sein OS alles ein bisschen anders interpretiert und 
verschlimmbessert. Daran wird nun seit 55 Jahren gebastelt. Daher gibt 
es x Geschichten und Interpretationen woher /bin, /sbin, /usr/bin und 
/usr/sbin kommen.

Dazu kommt dass sich keiner, auch bis heute nicht, 100% an die selbst 
gesetzten Standards hält.

Hier ist was ich im Kopf habe, wie es mal war:

/bin - Was zum Booten benötigt wird, bzw. wurde bevor /sbin kam. Die 
Programme müssen auf der Root-Partition liegen. Da zum Booten diverse 
Systemtools benötigt werden sammelten die sich dort an. Soweit man sie 
aus /etc rausgeworfen hatte ...

Dazu stehen dort auch normale Tools, die eben zum Booten benötigt 
werden, aber für normale Benutzer interessant oder sogar wichtig sind. 
Zum Beispiel die Bourne-Shell.

/sbin - Kam später hinzu. Als ich mit Unix angefangen habe gab es das 
noch nicht.

Das "s" steht nicht für System, su oder ähnliches, sondern für static. 
Als dynamisch gelinkte Programme bei Unix aufkamen fand es jemand 
wichtig die separat zu speichern. Statisch gelinkte Programme sind im 
Notfall wichtig wenn die dynamischen Libraries nicht ladbar sind, der 
ldd spinnt usw. Damit landeten in /sbin die Tools die ohne dynamisches 
Linken funktionieren, auch beim Booten. /bin behielt den Rest. Nicht 
selten gab es das selbe Programm zwei mal. Statisch gelinkt in /sbin, 
dynamisch gelinkt in /bin.

/usr/bin - Für Benutzer gedachte Programme. Heute würde man sagen 
Anwendungsprogramme, im Gegensatz zu Systemprogrammen. /usr war früher 
auch der Start für die Stammverzeichnisse der Benutzer, was heute /home 
ist. So war es damals ziemlich logisch Anwendungsprogramme in /usr/bin 
zu speicher.

Da es neben Root (Homeverzeichnis früher einfach /, heute /root) auch 
andere spezielle Systemuser gibt, wie das Druckersystem, landeten solche 
"Benutzer" auch in und unter /usr. Und die zugehörigen Programme unter 
/usr/bin

/usr lag gerne auf einer separaten Partition oder Platte. Daher konnte 
man dort keine Programme speichern die beim Booten gebraucht wurden.

/usr/sbin kam später hinzu, als die Aufteilung in dynamische und 
statisch gelinkte Programme kam. /usr/sbin waren die statisch gelinkten 
Anwendungsprogramme.

/usr wurde dann später geteilt. Dateien (Anwendungs-Programme, 
Libraries, Benutzer, etc.) die mit dem OS kamen blieben unter /usr. Zum 
Beispiel das Druckersystem. Echte Benutzer-Stammverzeichnisse wanderten 
nach /home. Externe Programmpakte sollten nach /opt. Allerdings hat sich 
/opt nicht sehr weit durchgesetzt.

Damit hast du auch die Erklärung warum manche Distributionen die sbin 
Verzeichnisse nicht im normalen Benutzerpfaden haben (wollen). Dort 
glaubt man zu wissen dass normale Benutzer nie und nimmer statisch 
gelinkte Programme brauchen. Was Blödsinn ist, wenn es kein dynamisch 
gelinktes Äquivalent in den bin Verzeichnissen gibt.

Abgesehen davon findet man auch schon mal dynamisch gelinkte Programme 
in sbin. Wenn jemand wieder nicht verstanden hat wofür sbin gedacht ist 
bzw. war, oder wenn jemand sbin umdefiniert hat zu "für 
Systemprogramme".

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Daniel A. schrieb:
> PS: Mir gefällt der Symlink nonsens aber auch nicht besonders. Statt
> /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen.
> Ok, dann hätte man mit `#!/bin/sh` usw. Probleme. Das ist aber auch
> irgendwie sowieso Mist. Man sollte mal einführen, dass `#!sh` wie
> `#!/usr/bin/env sh` funktioniert, oder irgend was in die Richtung. Aber
> irgendwie tun immer alle so, als könne man solche Altlasten nicht mehr
> ändern.

Komisch: jetzt tun die Distributoren etwas an den Altlasten, nämlich 
genau das, was Du "Symlink nonsens" nennst, achten dabei auf 
Abwärtskompatibilität, und dann ist es Dir auch wieder nicht Recht.

von Foobar (asdfasd)


Lesenswert?

Hannes schrieb:
> /sbin - Kam später hinzu. Das "s" steht nicht für System, su oder
> ähnliches, sondern für static.

Hast du eine Quelle dafür?  Hatte das schonmal irgendwo gelesen - schien 
mir aber "erfunden" zu sein.  An eine Trennung der statischen und 
dynamischen Programme kann ich mich nicht erinnern (kenn aber auch nicht 
alle Unixe).  Und zumindest bei SCO waren in /dbin keine dynamischen 
sondern DOS binaries ;-)  Der Übergang ging aber eh immer ziemlich fix - 
wenn man erstmal dyn konnte, hat mach schnell alles umgestellt.  /sbin 
ist aber immer noch da ...  Btw, in meinen */sbin gibt's genau ein 
static: ldconfig[1] - selbst init ist inzw dynamisch.

Zumindest für Linux sagt der FHS: "3.16. /sbin : System binaries"
   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html

Und hab gerade mal nachgeschaut: selbst in einer alten Linuxinstallation 
von '94 gab's schon /sbin.


--
[1] Und das scheint eher ein Versehen (gleiche Compileroptionen wie 
ld.so und das muss statisch sein).

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

https://de.wikipedia.org/wiki/Hashtabelle

Es ist vielleicht hilfreich, wenn man Linux und Unix trennt. Man müsste 
sich wirklich mehr auf Linux konzentrieren, die Linux-Geschichte selber, 
Linux-Spiele, Linux-Community, Linux-Zukunft, Linux-Kernel oder VMs z.B.
Wo möchte man denn mit Linux hin? In eine glückliche Desktop-Zukunft mit 
happy-legacy Mainframe-Hintergründen von 1970 (oder früher)?
Diablo1 und 2 wurde mit Talent, Mut und Hingabe entwickelt, und nicht 
mit Prinzipienreiterei, Dogmatismus oder gemütlich warmen Scheuklappen.
Gab es bei Linux eigentlich auch Crunch-Zeiten? Vielleicht wäre sowas 
mal gut, um etwas mehr Feinschliff, Ordnung und Kante hineinzubekommen.

Oder um es mal mit einem Bibeltext auszudrücken:
"Also, weil du lau bist und weder heiß noch kalt, werde ich dich 
ausspeien aus meinem Munde."
(Offenbarung 3,16)

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

Jack V. schrieb:
> Ein T. schrieb:
>> An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher.
>
> Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf
> alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird,
> ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann?

Auch ohne dieses Zeitfenster konnte jeder User einfach so alle Rechte 
bekommen. Besonders bequem fand ich "sudo su -". Ist das immer noch so? 
Auch bei der Ubuntu Server Edition?

Ubuntu liefert eben Produkte, die für eine bestimmte Anwendung optimiert 
sind. Deshalb ist das kein Problem. Auf einem privaten Desktop PC ist es 
total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem 
Server gibt es gefälligst keine User mit Shell.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hannes J. schrieb:
> /sbin - Kam später hinzu. Als ich mit Unix angefangen habe gab es das
> noch nicht.

Korrekt. /sbin gab es in den 80ern, als die UNIX-Rechner tatsächlich 
noch in separaten Server-Räumen stand, wo nur der Admin Zugang hatte, 
noch gar nicht. Hier gab es lediglich die Unterscheidung /bin und 
/usr/bin.

Unterschied: Unter /bin waren die allernotwendigsten Programme, um ein 
UNIX im Single-User-Mode zu starten, damit man Wartungsarbeiten 
durchführen konnte (sh, mount, fsck & Co).

Unter UNIX System V (bis SVR3) gab es kein /sbin, da bin ich mir 100%ig 
sicher. Das /sbin wurde meiner Kenntnis nach das erste Mal unter BSD 
2.11 gesichtet. Das war aber erst Anfang der 90er. SVR4 hatte auch 
einiges aus der BSD-Welt übernommen, soweit ich weiß, auch das 
/sbin-Verzeichnis.

Ob damals die allerersten Linux-Distributionen auch schon ein /sbin 
enthielten? Da bin ich mir nicht ganz sicher.

Siehe auch: https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

: Bearbeitet durch Moderator
von Norbert (der_norbert)


Lesenswert?

Rbx schrieb:
> Oder um es mal mit einem Bibeltext auszudrücken:
> "Also, weil du lau bist und weder heiß noch kalt, werde ich dich
> ausspeien aus meinem Munde."
> (Offenbarung 3,16)

Um es mal mit Frank Sinatra zu sagen:
To be do be doooo…

von Jack V. (jackv)


Lesenswert?

Bauform B. schrieb:
> Auf einem privaten Desktop PC ist es
> total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem
> Server gibt es gefälligst keine User mit Shell.

Verseuchter Desktop-PC ist total egal? Das Problem mit Malware ist: die 
macht (erstmal) nicht alles offensichtlich kaputt, sodass man auf die 
Idee kommt, vom USB-Stick zu booten und das zu fixen. „Gute“ Malware 
bleibt (erstmal) möglichst unbemerkt und nistet sich ein, und macht 
vielleicht ’ne Backdoor auf, oder etabliert eine Verbindung zum 
CC-Server. Oder sie macht schon mal im Hintergrund deine Backups 
unbrauchbar. Der normale User bekommt das nicht automatisch mit, und die 
Zielgruppe der Buntus schon gar nicht. Denn normale User sind eher nicht 
die, denen ’ne 500ms-Verzögerung so komisch vorkommt, dass sie da mal 
nachschauen …

Und das mit dem Server – nun, ich hoffe, dass hier keiner von etwa 
Uberspace mitliest. Die wissen das nämlich glücklicherweise noch nicht, 
dass der User keine Shell auf dem Server haben soll ;)

von Bauform B. (bauformb)


Lesenswert?

Jack V. schrieb:
> Bauform B. schrieb:
>> Auf einem privaten Desktop PC ist es
>> total egal, da boote ich notfalls von meinem USB-Stick. Und auf einem
>> Server gibt es gefälligst keine User mit Shell.
>
> Verseuchter Desktop-PC ist total egal?

Nein.

> Das Problem mit Malware ist: die macht (erstmal) nicht alles
> offensichtlich kaputt, sodass man auf die Idee kommt,
> vom USB-Stick zu booten und das zu fixen.

Ein kleines Missverständnis: ich wollte vom USB-Stick booten, um den PC 
anzugreifen :)

von Jack V. (jackv)


Lesenswert?

Bauform B. schrieb:
> Ein kleines Missverständnis: ich wollte vom USB-Stick booten, um den PC
> anzugreifen :)

Da bekomme ich allerdings ein Problem, das mit meinem Beitrag, den du 
gequotet hattest, zusammenzubringen: ein Angriff durch einen physisch 
anwesenden Angreifer ist nochmal eine ganz andere Situation.

Muss dich aber auch da enttäuschen: heutige Distributionen bieten bei 
der Installation Verschlüsselung an. Einen solchen Rechner kannst du 
dann gerne mit deinem Stick booten, aber mit dem Angreifen ist’s dann 
etwas schwierig. Klar, gibt auch da Wege – aber für Privatmenschen mit 
ihrem Desktop-PC geht bezüglich Kompromittierung durch physisch 
anwesende Angreifer die größte Gefahr von der Polizei aus (in manchen 
Bundesländern dürfen sie zur Installation von Überwachungssoftware 
unbemerkt in die Wohnung eindringen). Und das sollte man schon auch 
mitbekomment, wenn man nicht zu naiv ist.

Bauform B. schrieb:
> Besonders bequem fand ich "sudo su -". Ist das immer noch so?

Ja. Brauchst aber ein Passwort, wenn du nicht grad im Zeitfenster bist. 
Das ist entsprechend kein Problem. Ob jemand nun mittelbar über sudo 
beliebige Sachen als Root ausführt, oder unmittelbar mittels su zu Root 
wird, ist dann wohl auch egal.
Das größte Problem mit der kaputten ›sudo‹-Config sehe ich tatsächlich 
darin, dass es eben ein Zeitfenster gibt, in dem völlig ohne jede 
direkte Rückmeldung alles als Root ausgeführt werden kann. Erschwerend 
kommt hinzu, dass viele User mittlerweile zu glauben scheinen, dass man 
›sudo‹ vor alles schreiben müsse, ihnen also die Bedeutung davon nicht 
einmal mehr bewusst zu sein scheint. Beispiele dafür lassen sich in den 
einschlägigen Foren leider zuhauf finden.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Foobar schrieb:
> Hannes schrieb:
>> /sbin - Kam später hinzu. Das "s" steht nicht für System, su oder
>> ähnliches, sondern für static.
>
> Hast du eine Quelle dafür?

Daran kann ich mich auf "richtigen" UNIXen auch noch erinnern, unter 
Linux hat es das aber -- wenn überhaupt -- schon früh nicht mehr 
gegeben. Der Filesystem Hierarchy Standard (FHS, FSSTND) in Version 1.0 
vom 14.2.1994 [1] sagt:

"3.4. /etc : Machine-local system configuration

No binaries should go directly into /etc.  Binaries that would have, in
the past, been found in /etc should now be placed in /sbin.  This
includes such files as init, getty, and update.  Binaries such as
hostname that are used by users as well as root should not be placed in
/sbin, but in /bin."

".10. /sbin : System binaries (binaries once kept in /etc)

Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin.  /sbin typically
contains files essential for the booting phase of starting the system
up.  Anything executed after /usr is known to be mounted (when there are
no problems) should be placed into /usr/sbin.  Local-only system
administration stuff should now be placed into /usr/local/sbin.

[...]

Users should have execute permission for everything in /sbin that can be
executed by non-root users.  The division between /bin and /sbin was not
created for security reasons or to prevent users from seeing the OS, but
to provide a good division between binaries that everyone uses and the
ones that are primarily used for administration tasks.  There is no
inherit security advantage in making /sbin off-limits for users."

von Monk (roehrmond)


Lesenswert?

Daniel A. schrieb:
> Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen.

Wirst du alle Programme und Scripte der Welt (oder wenigstens einer 
Linux Distribution) anpassen, damit sie danach noch funktionieren?

von Foobar (asdfasd)


Lesenswert?

Daniel A. schrieb:
> Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen.

Und wenn wir schon dabei sind, mal endlich das "v" wieder aus der 
deutschen Schrift entfernen: follkommen überflüssig, ist entweder ein 
"f" (Fielfraß) oder ein "w" (Wentil).  Bei Falschbenutzung: Kopf ab.

von Rbx (rcx)


Lesenswert?

Unix (nur so grob):
/bin
/bin/sh
/boot
/dev
/dev
/etc (viel Benutzerkontensteuerung)
/usr
/usr/lib/uucp

Linux:
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (s.o.) - ist 
halt die bessere Referenz gerade.

Ich hatte auch mal in den Büchern nachgesehen, aber besonders 
geistreiches oder tiefschürfendes war zu /sbin nicht zu finden.
(auch hier nicht: 
https://askubuntu.com/questions/308045/differences-between-bin-sbin-usr-bin-usr-sbin-usr-local-bin-usr-local)

Und von der Logik her kann doch der admin-Quark genauso gut unter 
/bin/admin laufen.
Bei Windows gab es auch mal so eine lächerliche Posse, weil man 
plötzlich Hexeditoren oder den ProcessExplorer nicht mehr ohne 
Admin-Passwort einsetzen konnte. Und auf der anderen Seite konnte man 
mit debug auf der SD-Karte von da aus überall auf C: zugreifen und auch 
drauf schreiben..
Und bei Linux habe ich auch gelegentlich Fehlermeldungen, die darauf 
hinweisen, dass Wine oder Steam gelegentlich offenbar den gcc brauchen..

/sbin angeblich immer für "essentielle" "Systemprogramme" was immer sich 
man dazu vorstellen kann. Ist doch aber auch ein wenig von Betrachter 
abhängig.

Und bei Windows genauso: Wozu soll das gut sein, dass ich auf der 
Benutzerebene keinen Hexeditor als einfacher Benutzer nutzen kann?
Das hat eher was mit Bevormundung zu tun.
Und Virenscanner sind ja ganz ähnlich drauf.

Und wie man weiter (ganz) oben (Disketten) sieht: Klappt die 
Bevormundung nicht immer so, wie das in der Realworld-Alltagswelt 
abläuft.

Ist deswegen die Benutzerkontenverwaltung blöd? Finde ich jetzt nicht. 
Aber man kann auch Ärger mit dem Rechenzentrum bekommen, wenn gewisse 
Sachverhalte und Regeln nicht transparent sind oder nicht klar auf den 
Tisch gelegt werden.
Man könnte ja soweit gehen, bestimmte Sachen gar nicht anzubieten.

...
Naja, und Schulungen gibt es wohl auch kaum noch. Das war früher noch 
ein wenig anders.
So grundsätzlich, und das ist meine Erfahrung mit dem ODP sollten sich 
Ordnungsstrukturen zwar an Vorgaben halten, aber nicht zwingend 
vorgeben. Teilweise war es ja manchmal auch nötig, Zwischenordungen 
herzurichten. Über allem stand A-Z mit als erfolgreichste Ordnung. 
Zwischenordnung wäre da z.B. A, H, L, Sonstige, weil die meisten 
Einträge eben nur in A, H und L gingen. Aber da gab es auch schon 
Rumgeheule. Viele Interessengruppen halt..manchmal gab es Streiterei 
über eine Kategorie, die es nicht geben soll, manchmal gab es Streiterei 
oder Geheule, weil man wieder mal von Übereditoren (eher unabsichtig im 
Zuge gewisse Aufräumarbeiten - kennt man ja hier auch) aus einer 
bestimmten Ecke gelöscht wurde, oder die eigenen Arbeiten gelöscht 
wurden ..hach ja und dann sind wir wieder bei
https://de.wikipedia.org/wiki/Chaosforschung
https://de.wikipedia.org/wiki/Komplexität
https://de.wikipedia.org/wiki/Panta_rhei

Ist das jetzt nicht offtopic? Nein, gar nicht. Ordnungen sollen helfen, 
das (Zusammen)Leben zu erleichtern.
Was sie aber nicht machen sollten, ist genau umgekehrt, das 
(Zusammen)Leben zu behindern.
Ohne einen gewissen Zwang gibt es aber auch keine Freiheit. Vorgegebene 
Ordnungen nehmen einem z.B. Entscheidungskosten ab.

Bauform B. schrieb:
> nur zwecks meiner Neugier: warum sollen normale User Programme aus /sbin
> und /usr/sbin nicht starten (bzw. nur umständlich)?

Soweit ich das richtig verstehe, haben /sbin-Ordner unter /usr überhaupt 
nichts verloren und /sbin selbst (abgesehen davon, dass das kein Ordner 
für Userprogramme ist) ist eher so ein Dummy-Ding, das es zwar gibt, 
aber keiner so richtig weiß, wozu das gut sein soll.
Bei Windows sind die ganzen Systemsachen bei Windows/System, schon seit 
Urzeiten, und da ist bisher auch noch keiner dran gestorben ;)

von Ralf D. (doeblitz)


Lesenswert?

Bauform B. schrieb:
> Besonders bequem fand ich "sudo su -".

Hüalp. Das ist krank. Da nimmt man
1
sudo -i
.

von Jack V. (jackv)


Lesenswert?

Nicht ›sudo su -c 'sudo su -c "bash"'‹?

von Norbert (der_norbert)


Lesenswert?

Jack V. schrieb:
> Nicht ›sudo su -c 'sudo su -c "bash"'‹?

Noch ein paar Versuche und wir sind bei der guten alten rekursiven 
Shell-Bombe.

von Daniel A. (daniel-a)


Lesenswert?

Steve van de Grens schrieb:
> Daniel A. schrieb:
>> Statt /bin -> /usr/bin usw., sollte man einfach /bin ganz weg lassen.
>
> Wirst du alle Programme und Scripte der Welt (oder wenigstens einer
> Linux Distribution) anpassen, damit sie danach noch funktionieren?

Bei den Skripten mit sed schnell gemacht, bei guten Skripten muss man 
nur die erste Zeile anpassen. Bei zu Kompilierenden Programmen sollte 
man sowieso eine Konstante für den Prefix dazutun, was es ja meistens eh 
schon gibt, oder halt $PATH nutzen. Und wenn der ein oder andere dadurch 
lernt, nicht einfach ungeprüft Skripte aus dem Internet laufen zu 
lassen, ist das noch ein Zusatzbonus.

Sheeva P. schrieb:
> Komisch: jetzt tun die Distributoren etwas an den Altlasten, nämlich
> genau das, was Du "Symlink nonsens" nennst

Wenn man /bin usw. entfernt, dann gefälligst richtig. Mit einen Symlink 
ist / immernoch mit dem Eintrag zugemüllt. Ein Symlink ist ein Hack. 
Eine scheinlösung. Das einzige was man davon hat, ist, das nachher 
Programme als /bin und anderswo auch noch als /usr/bin hartkodiert 
werden. Dann kann man gar kein echtes /bin Verzeichnis mehr haben, und 
alles ist so richtig kaputt.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Es ist vielleicht hilfreich, wenn man Linux und Unix trennt. Man müsste
> sich wirklich mehr auf Linux konzentrieren, die Linux-Geschichte selber,
> Linux-Spiele, Linux-Community, Linux-Zukunft, Linux-Kernel oder VMs z.B.
> Wo möchte man denn mit Linux hin? In eine glückliche Desktop-Zukunft mit
> happy-legacy Mainframe-Hintergründen von 1970 (oder früher)?

Ich habe eine Weile lang darüber nachgedacht, was ich auf so etwas 
antworten kann. Mir sind kluge, aber leider keine freundlichen Dinge 
eingefallen.

> Diablo1 und 2 wurde mit Talent, Mut und Hingabe entwickelt

Stimmt, aber das trifft auch auf Solaris, Free-, Net- und OpenBSD zu.

> Gab es bei Linux eigentlich auch Crunch-Zeiten? Vielleicht wäre sowas
> mal gut, um etwas mehr Feinschliff, Ordnung und Kante hineinzubekommen.

Wie vor einiger Zeit hier jemand geschrieben hat, ist Linux das mit 
Abstand erfolgreichste Betriebssystem auf der Erde, und meines Wissens 
auch auf dem Mars. Das wäre nicht so, wenn es zu wenig "Feinschliff, 
Ordnung und Kante" hätte. Die "Ordnung" und die "Kante" sind übrigens 
nicht zuletzt Folgen der POSIX-Spezifikation und des Bemühens der 
Linux-Entwickler, sie einzuhalten.

Aber Linux ist, und bleibt hoffentlich, anders als die üblichen Systeme 
für den Desktop. Linux ist offen, sehr leistungsfähig und extrem 
flexibel. Aber dafür verzeiht es nichts und nimmt den Benutzer in die 
volle Verantwortung.

Das ist -- die klugen Anwesenden mögen bitte verzeihen, dass mein 
Vergleich hinkt -- wie der Vergleich zwischen einem Rennauto und einem 
handelsüblichen Straßenfahrzeug. Mit meinem 2002ti kann ich Donuts auf 
die Strasse malen, da würden bei meinem Golf sofort alle Lämpchen 
angehen und mich fragen, ob ich noch alle Latten am Zaun habe. Zurecht, 
der BMW ist für andere Bedingungen (und Bediener) gemacht als der 
Golf...

Vor einiger Zeit gab es hier einen Thread, da hat jemand gefragt, wie er 
die Unterstützung von Windows abschalten könne. Dieser Thread hat mir 
die Augen geöffnet. Während Windows versucht zu reparieren, was es als 
defekt ansieht, macht ein Linux einfach genau das, was ihm gesagt wird.

Und genau das gilt auch für den Desktopbereich. Linux ist wunderbar auf 
dem Desktop, braucht dazu aber kompetente Benutzer und / oder Admins. 
Wer seinen Linux-Desktop und das System darunter beherrscht, kann damit 
nicht nur Spass haben, sondern in vielen Fällen auch extrem effizient 
damit arbeiten. Er muss es halt können, sonst Enttäuschungen 
vorhersehbar.

> Oder um es mal mit einem Bibeltext auszudrücken:
> "Also, weil du lau bist und weder heiß noch kalt, werde ich dich
> ausspeien aus meinem Munde." (Offenbarung 3,16)

Im Moment ist Linux das heißeste System der Welt und wie gesagt, auch 
auf dem Mars. Bei allen aktuellen IT-Themen hat Linux die Nase vorn, vom 
Distributed über das Super- bis hin zum Cloud-Computing, Machine- und 
Deep Learning, und natürlich bei der Containerisierung und dem 
Clustering.

Auch auf dem Desktop hat es vielfach die Nase vorn. Die "Aktivitäten" 
meines KDE nutze ich zwar selten. Aber die virtuellen Desktops mit den 
Aufgaben zu verknüpfen, die ich damit erledigen will, und dabei Dinge zu 
automatisieren, das ist manchmal eine sehr feine und komfortable Idee. 
Und apropos virtuelle Desktops: wo hat dieses Microsoft Windows sich die 
wohl abgeschaut? :)

Allerdings werden Deine Anwendungsfälle, Windows-Spiele unter alten 
Versionen von Linux zu nutzen, für die Linux-Entwicker vermutlich kaum 
die allerhöchste Priorität geniessen. Das tut mir leid für Dich. Aber 
können wir uns vielleicht trotzdem darauf einigen, dass das weder 
Maßstab noch Ziel ist? Merci.

von Sheeva P. (sheevaplug)


Lesenswert?

Jack V. schrieb:
> Ein T. schrieb:
>> An der sudo-Konfuguration der Ubuntus ist nichts kaputt oder unsicher.
>
> Du findest es nicht unsicher, wenn in einer Shell nach einem sudo-Aufruf
> alles Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird,
> ohne weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann?

Ich kann nicht für den Typ sprechen. Aber nein, das finde ich weder 
kaputt noch unsicher. Im Gegenteil: wenn ich administrative Arbeiten zu 
erledigen habe, ist das komfortabel. Was wäre der Angriffsvektor?

von Sheeva P. (sheevaplug)


Lesenswert?

Bauform B. schrieb:
> Auch ohne dieses Zeitfenster konnte jeder User einfach so alle Rechte
> bekommen. Besonders bequem fand ich "sudo su -". Ist das immer noch so?
> Auch bei der Ubuntu Server Edition?

Ja. Und wenn Du eine passende Datei in /etc/sudoers.d/<username>, oder 
es in der /etc/sudoers.conf ablegst, dann bekommst Du sogar ohne 
Passwort und ohne Paßwortabfrage sofort Rootrechte. Oder halt die 
Rechte, etwas als Root zu tun, das sonst leider nicht ginge.

> Ubuntu liefert eben Produkte, die für eine bestimmte Anwendung optimiert
> sind. Deshalb ist das kein Problem. Auf einem privaten Desktop PC ist es
> total egal, da boote ich notfalls von meinem USB-Stick.

Darum geht es gar nicht... wenn Du Benutzer hast, die bestimmte Dinge 
tun sollen, oder mit mehreren Sysops auf demselben System arbeiten 
möchtest, kommen mir so ein paar Möglichkeiten in den Sinn. Zum Beispiel 
SE-Linux, AppArmor, grsecurity oder RSBAC. Will ich das konfigurieren? 
Im Ernst?

Solche Aufwände gönne ich mir nur bei den Systemen, die besonders 
exponiert sind und / oder besonders sensible Daten halten. 
Datenbankserver aller Art, wenn sie exponiert werden müssen, oder 
Firewalls kommen mir da in den Sinn.

Die elegantere Alternative ist nun einmal sudo(1). Da kann ich für meine 
User relativ präzise festlegen, was sie tun dürfen, mit oder ohne 
Passworteingabe. Credential Caching kann man machen, das ist natürlich 
konfigurierbar, und auf meinen Desktops und Schleppis nutze ich das 
auch.

Auf die meisten meiner Server kommt ohnehin nur, wer erstens ein 
passendes Zertifikat fürs VPN und zweitens einen gültigen SSH Private 
Key hat. Und um sich dann per sudo(1) weitere Privilegien zu 
verschaffen, bedarf es dennoch noch eines Passworts. Voll unsicher, na 
klar... :)

> Und auf einem Server gibt es gefälligst keine User mit Shell.

Na logo. Und wenn, sind die über sudo(1) und / oder eine restricted 
Shell so weit wie möglich auf das beschränkt, was sie tun dürfen. :)

von Sheeva P. (sheevaplug)


Lesenswert?

Jack V. schrieb:
> Verseuchter Desktop-PC ist total egal?

Ja, total, absolut, und vollkommen egal.

Wenn einer meiner Desktops geseucht ist, dann ist das Kind ja bereits in 
den Brunnen gefallen. Davor schützt uns nichts. Da greift $Kackvogel 
einfach ab, was er will: Deine SSH-Keys, Deine VPN-Schlüssel, Deine 
Tastatureingaben und damit Deine Passworte... you get the idea.

> oder etabliert eine Verbindung zum CC-Server.

Ich glaube nicht, daß Chatcity was damit zu tun hat. :)

von Jack V. (jackv)


Lesenswert?

Sheeva P. schrieb:
> Was wäre der Angriffsvektor?

Rhetorische Frage?

Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine 
Antwort gefunden (die im Übrigen einen realen Hintergrund hat). Da du 
offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du 
auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit 
dafür kann ich also sparen.

Sheeva P. schrieb:
> wenn ich administrative Arbeiten zu
> erledigen habe, ist das komfortabel.

Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹ 
– das ist noch komfortabler und bietet, anders als ›sudo‹ in der 
kaputten Konfiguration, auch zeitlich und visuell eine scharfe Trennung 
zwischen Anwender- und Administratoraccount.

von Sheeva P. (sheevaplug)


Lesenswert?

Jack V. schrieb:
> Sheeva P. schrieb:
>> Was wäre der Angriffsvektor?
>
> Rhetorische Frage?

Nein.

> Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine
> Antwort gefunden (die im Übrigen einen realen Hintergrund hat).

Tatsächlich habe ich Deinen Beitrag gelesen und sogar verstanden, lieber 
Kollege. Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder, 
anders gefragt: dem realen Hintergrund?

> Da du
> offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du
> auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit
> dafür kann ich also sparen.

Sparsamkeit ist zweifellos eine hohe Kunst. :)

> Sheeva P. schrieb:
>> wenn ich administrative Arbeiten zu
>> erledigen habe, ist das komfortabel.
>
> Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹
> – das ist noch komfortabler

Das halte ich für ein Gerücht, denn... ich habe ja diese Dings... 
Kollegen.

Dieses su(1) ist da leider ein bisschen doof. Dann muss jeder nämlich 
dasselbe Passwort kennen, nämlich das Root-Passwort. Grandios.

AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was 
hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA, 
SOX, ...?

> und bietet, anders als ›sudo‹ in der kaputten Konfiguration, auch
> zeitlich und visuell eine scharfe Trennung zwischen Anwender- und
> Administratoraccount.

Möchtest Du mich ärgern?

von Daniel A. (daniel-a)


Lesenswert?

Klar P. schrieb:
> manchmal deucht mir man will dem unterprivilegierten user su mit
> sudo austreiben  ...

Das ist mittlerweile übrigens veraltet. Heute nimmt man run0 von 
systemd...

von Jack V. (jackv)


Lesenswert?

Sheeva P. schrieb:
> Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder,
> anders gefragt: dem realen Hintergrund?

Wie geschrieben: es gab Vorfälle.

Sheeva P. schrieb:
> Das halte ich für ein Gerücht, denn... ich habe ja diese Dings...
> Kollegen.

Und das hat mit der zitierten Aussage genau was zu tun?

Sheeva P. schrieb:
> AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was
> hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA,
> SOX, ...?

Ich glaube, hier liegt das Missverständnis: du gehst von einer 
kontrollierten Umgebung mit strengen Regeln im Firmenkontext (oder 
Schlimmerem) aus, und davon, dass ausschließlich qualifizierte Leute in 
der sudoers stehen. Alle Anderen in diesem Thread jedoch nicht (wobei 
ich mir beim Typen nicht vollkommen sicher bin, der mag einen ähnlichen 
Hintergrund wie du haben).

In deiner kleinen Welt mag deine Ansicht vollkommen und richtig sein. In 
der Welt da draußen ist die Konfiguration schlicht gefährlich.

Fun fact am Rande: in der Standard-Buntu-Systemkonfiguration kann 
jemand, der mittels ›sudo‹ faktisch volle Rootrechte erlangt hat, dann 
auch problemlos die korrespondierenden Logeinträge manipulieren. Da ist 
dann ggf. nicht mehr viel mit Nachvollziehbarkeit – im Gegenteil.

Sheeva P. schrieb:
> Möchtest Du mich ärgern?

Möchtest du denn mich ärgern?

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Jack V. schrieb:
> Sheeva P. schrieb:
>> Aber ich frage nach Implikation und Wahrscheinlichkeiten? Oder,
>> anders gefragt: dem realen Hintergrund?
>
> Wie geschrieben: es gab Vorfälle.

Vorfälle. Please elaborate?

> Sheeva P. schrieb:
>> AFAIK macht su(1) auch keinen Logeintrag, sudo(1) hingegen schon. Was
>> hat es eigentlich mit dieser "Auditability" auf sich? ISO27k, HIPAA,
>> SOX, ...?
>
> Ich glaube, hier liegt das Missverständnis: du gehst von einer
> kontrollierten Umgebung mit strengen Regeln im Firmenkontext (oder
> Schlimmerem) aus, und davon, dass ausschließlich qualifizierte Leute in
> der sudoers stehen.

Ja, natürlich. Ich entscheide mit meinen Kollegen, was in den sudoers 
steht.

Trotzdem fehlt mir noch eine Idee, wie sich das ausnutzen ließe. Klar 
habe ich Ideen, aber: die erfordern, dass der Angreifer schon "root" 
hat, also das Huhn bereits längst im Topf ist. Please elaborate.

> In deiner kleinen Welt mag deine Ansicht vollkommen und richtig sein. In
> der Welt da draußen ist die Konfiguration schlicht gefährlich.

Nein, ist sie nicht.

von Jack V. (jackv)


Lesenswert?

Sheeva P. schrieb:
> Vorfälle. Please elaborate?

Nein, not in the public. So groß ist mein Ego dann auch nicht, als dass 
ich ’nem völlig unbekannten Typen die Sachen in einem öffentlich 
lesbaren Forum darlegen würde.

Sheeva P. schrieb:
> Trotzdem fehlt mir noch eine Idee, wie sich das ausnutzen ließe.

Und du kommst tatsächlich nicht von alleine darauf? Stell dir einfach 
vor, dass da normale User am Rechner sitzen. Diese User spielen in dem 
Szenario eine Rolle, und die kaputte ›sudo‹-Konfiguration hilft dabei 
sehr.

Sheeva P. schrieb:
> Nein, ist sie nicht.

So naiv war ich nie.

von Oliver S. (oliverso)


Lesenswert?

Sheeva P. schrieb:
> Wie vor einiger Zeit hier jemand geschrieben hat, ist Linux das mit
> Abstand erfolgreichste Betriebssystem auf der Erde, und meines Wissens
> auch auf dem Mars.

Das ist nun allerdings eine sehr fragwürdige Quelle.
Linux ist sicherlich das erfolgreichste Open Source Betriebssystem auf 
„richtigen“ Computern, und das erfolgreichste im IoT-Bereich. Letzteres, 
weils kostenlos, leistungsfähig und flexibel ist, in dieser Reihenfolge.

Und warum das auch so bleibt, zeigt die Diskussion hier über die wahre 
Lehre bzgl. sudo.

Oliver

von Bauform B. (bauformb)


Lesenswert?

Noch ein Argument für die Aufteilung ist auch aus der Mode gekommen: 
single user mode. Mal eben telinit 1, reparieren, telinit 2 wurde schon 
aufgegeben, als init noch init hieß. Wann habt ihr das zum letzten Mal 
benutzt?

https://www.linux-magazine.com/Issues/2016/187/Doghouse-Filesystem-Standards

Die Geschichte von Linux auf dem Mars ist ja vollkommen irre:
"Watching the Mars rover, maddog is delighted to observe that the small 
helicopter it carries named Ingenuity has many off-the-shelf components 
and runs under Linux using free and open source software."

Soweit so gut; Commercial off-the-shelf components (COTS) sind ja ein 
Mittelweg zwischen unbezahlbar-Military und Schrott-Commercial. Aber 
das?!

"Many of the other parts for the helicopter were ordered from SparkFun 
electronics."

"It runs an Open-Source Flight Software Framework called "F' (F Prime)" 
which runs on a Raspberry Pi 3 under Linux."

https://www.linux-magazine.com/Issues/2021/246/maddog-s-Doghouse

von Martin H. (horo)


Lesenswert?

Bauform B. schrieb:
> Linux auf dem Mars

Auch hier wird es sicher etliche geben, die ein Bit oder Byte dazu 
beigetragen haben. Eigentlich trivial, aber im nichttechnischen 
Freundeskreis ruft es dennoch Erstaunen hervor.

https://github.com/users/Ho-Ro/achievements/mars-2020-contributor

von Ein T. (ein_typ)


Lesenswert?

Jack V. schrieb:
> Hättest du den zitierten Beitrag weitergelesen, hättest du schonmal eine
> Antwort gefunden (die im Übrigen einen realen Hintergrund hat).

Also ich habe den besagten Beitrag gelesen und halte ihn für Unfug. Daß 
irgendwelche Spatzenhirne unverstandenes Zeug aus dubiosen Quellen in 
ihre Shell eingeben, ist kein Argument für irgendwas, außer für die 
Hirnlosigkeit dieser Spatzenhirne. Ähnliches gilt für Deinen "realen 
Hintergrund". Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß 
Linux kompetente Benutzer voraussetzt, insofern ist es bestenfalls ein 
Ablenkungsmanöver, hier mit möglichen Fehlern irgendwelcher Spatzenhirne 
zu argumentieren.

Im Übrigen ist der besagte Beitrag aber auch sachlich falsch. Es ist 
nämlich nicht so, daß "in einer Shell nach einem sudo-Aufruf alles 
Weitere, das darin innerhalb einer gewissen Zeit aufgerufen wird, ohne 
weitere Rückfrage und ohne Hinweis Rootrechte bekommen kann", wie Du 
geschrieben hast. Richtig ist, daß man -- und zwar man selbst, nicht 
irgendeine magische Engelsgestalt aus einem Wi-wa-wunderland -- immer 
noch "sudo" davor eingeben muß.

> Da du
> offensichtlich nicht einmal das getan hast, gehe ich davon aus, dass du
> auch nicht an einer weitergehenden Antwort interessiert bist – die Zeit
> dafür kann ich also sparen.

Wenn sie genauso "klug" ist wie der besagte Beitrag, kannst Du Dir und 
uns diese Zeit wirklich ersparen.

> Und wenn ich administrative Aufgaben zu erledigen habe nutze ich ›su‹
> – das ist noch komfortabler und bietet, anders als ›sudo‹ in der
> kaputten Konfiguration, auch zeitlich und visuell eine scharfe Trennung
> zwischen Anwender- und Administratoraccount.

In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet 
werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger 
unsicher als sudo. Zudem sind gesetzte Root-Paßworte anfällig für 
allerlei Angriffe. Vielleicht hast ja sogar Du schon einmal von 
Rainbowtabellen, Wörterbuch- und Bruteforce-Angriffen gehört, ja?

sudo(1) bietet übrigens dieselbe "scharfe Trennung zwischen Anwender- 
und Administratoraccount". Man muß es nämlich eingeben, um höhere 
Privilegien zu erlangen. Es ist nicht so, daß man nach der Benutzung 
von sudo plötzlich für einen gewissen Zeitraum Administratorrechte als 
normaler Benutzer hat. Man muß "sudo" hinschreiben. Selbst. Explizit. 
Ausdrücklich. Und daran ist nichts, aber auch gar nichts unsicher.

von Ein T. (ein_typ)


Lesenswert?

Jack V. schrieb:
> Sheeva P. schrieb:
>> Vorfälle. Please elaborate?
>
> Nein, not in the public. So groß ist mein Ego dann auch nicht, als dass
> ich ’nem völlig unbekannten Typen die Sachen in einem öffentlich
> lesbaren Forum darlegen würde.

Du argumentierst also mit angeblichen "Vorfällen", kannst und willst sie 
jedoch auch auf ausdrückliche Nachfrage nicht erläutern. Damit sind 
Deine angeblichen "Vorfälle" nichts als unbelegte Behauptungen -- und 
fallen als Argument somit komplett aus.

von Ein T. (ein_typ)


Lesenswert?

Ein T. schrieb:
> In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet
> werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger
> unsicher als sudo.

Korrektur: ...mit Abstand weniger sicher...

von Jack V. (jackv)


Lesenswert?

Ein T. schrieb:
> In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet
> werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger
> [sicher] als sudo.

In deiner realen Welt reicht unter Buntu ein ›sudo passwd‹, um das 
Passwort zu setzen. Oder halt ›sudo bash‹, ›sudo su‹ oder auch ›sudo -i‹ 
– was den Rest deiner „Argumentation“ irgendwie ad absurdum führt.

Merkt ihr das denn nicht selbst, wenn ihr mit der angeblichen höheren 
Sicherheit der kaputten Konfiguration gegenüber einem Rootpasswort 
argumentiert? Damit, dass Aufrufe via ›sudo‹ ja einwandfrei nachprüfbar 
geloggt würden? Seht ihr echt nicht, dass es lediglich ein Aufruf von 
›sudo‹ in dieser kaputten Konfiguration ist, um das alles auszuhebeln? 
Dass genau das das Problem dieser Konfiguration ist?

Keiner sagt was gegen ›sudo‹ ansich – ich mag das Tool sehr. Aber ihr 
verteidigt hier ’ne Konfiguration mit Argumenten, die sich angesichts 
ebendieser Konfiguration in Luft auflösen.

Ein T. schrieb:
> Man muß "sudo" hinschreiben. Selbst. Explizit.
> Ausdrücklich. Und daran ist nichts, aber auch gar nichts unsicher.

Ja … weil das natürlich in einem C&P-String nie auftauchen kann, und in 
Scripten selbstverständlich auch nicht. Is klar …

Ein T. schrieb:
> Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß
> Linux kompetente Benutzer voraussetzt, insofern ist es bestenfalls ein
> Ablenkungsmanöver, hier mit möglichen Fehlern irgendwelcher Spatzenhirne
> zu argumentieren.

Deiner Ansicht nach richtet sich Buntu mit seiner kaputten Konfiguration 
also an kompetente Linuxnutzer. Bist du denn auch einer dieser … 
„kompetenten“ Linuxnutzer, für die Buntu geschaffen wurde? Das würde in 
der Tat einiges erklären …

In meiner Welt, die ich für recht real halte, benötigt ein kompetenter 
Linuxnutzer die kaputte Konfiguration nicht als Krücke, sondern er 
richtet sich sein ›sudo‹ direkt passend und sicher ein. Er ist ja 
schließlich kompetent.

OT: kennst du das Geheimnis, das hinter dem „Bearbeiten“-Link unter 
einem Beitrag steht? Ist spannend: man sieht nicht so dämlich aus, wie 
wenn man für eine Antwort drei Beiträge schreibt.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Jack V. schrieb:
> Ein T. schrieb:
>> In der realen Welt gibt es Systeme, die von mehreren Leuten verwaltet
>> werden, und die Weitergabe von Root-Paßworten ist mit Abstand weniger
>> [sicher] als sudo.
>
> In deiner realen Welt reicht unter Buntu ein ›sudo passwd‹, um das
> Passwort zu setzen. Oder halt ›sudo bash‹, ›sudo su‹ oder auch ›sudo -i‹
> – was den Rest deiner „Argumentation“ irgendwie ad absurdum führt.

In meiner realen Welt gibt es mehrere Möglichkeiten, ein root-Paßwort zu 
setzen. Mein Punkt ist: ich will gar kein root-Paßwort setzen. Denn 
jedes Paßwort, insbesondere eines zu einem bekannten Account, ist 
potentiell ein Risiko. Das gehe ich nicht ein, wenn ich das nicht muß. 
Und ich muß es ja nicht, denn ich habe sudo(8). Dadurch hat ein 
Angreifer überhaupt gar keine Chance, mein root-Paßwort zu knacken.

Deswegen gibt es auch keine Notwendigkeit für mich, mir mehrere Paßworte 
zu merken. Auch das ist eine feine Sache, denn so kann ich mich für das 
eine Paßwort, das ich brauche und mir merken muß, auf ein besonders 
starkes und langes Paßwort allem Drum und Dran konzentrieren.

Deswegen hat auch das Credential Caching von sudo(8) eine feine Sache, 
denn dadurch muß ich mein langes Paßwort nicht alle naselang eintippen 
und komme auch deswegen nicht auf die Idee, ein kurzes, mithin 
schwaches, dafür aber schnell eintippbares Paßwort zu wählen. 
Ebensowenig komme ich auf die Idee, ständig als Benutzer root, sondern 
mit den geringstmöglichen Privilegien zu arbeiten und eine root-Shell 
nur zu starten, wenn ich sie wirklich brauche.

Insofern haben die Standardkonfiguration von sudo(8) und auch die von 
Ubuntu zwar keine riesigen Vorzüge vor dem, was Du vorschlägst. Im 
Endeffekt dürfte das Sicherheitssniveau der beiden Lösungen jedoch 
vergleichbar sein.

Ich kenne auch keine Sicherheitsregularien oder -Empfehlungen, die sich 
gegen sudo(8) aussprechen. Im BSI-Grundschutzhandbuch und den 
Ausführungen zu PCI-DSS steht IIRC ein bisschen zur Konfiguration von 
sudo(8), aber keines dieser Werke spricht sich gegen sudo(8) aus oder 
würde gar empfehlen, das Credential Caching zu deaktivieren. Wozu auch?

Nebenbei bemerkt, wenn Du Dein Sicherheitsniveau wirklich nachhaltig 
erhöhen möchtest, empfehle ich Dir eine Mehrfaktor-Authentifizierung zum 
Beispiel mit dem Google Authenticator [1] und / oder One Time Passwords. 
Das kannst Du mit überschaubarem Aufwand über die Pluggable 
Authentication Modules (PAM) in der Datei /etc/pam.conf oder auf den 
meisten moderneren Distributionen in dem Verzeichnis /etc/pam.d/ 
einrichten und hast dann eine Stufe der Sicherheit erreicht, die heute 
als state of the art gilt.

[1] https://de.wikipedia.org/wiki/Google_Authenticator
[2] https://www.cl.cam.ac.uk/~mgk25/otpw.html

> Merkt ihr das denn nicht selbst, wenn ihr mit der angeblichen höheren
> Sicherheit der kaputten Konfiguration gegenüber einem Rootpasswort
> argumentiert?

Meine Güte, was gibts denn da zu merken? Meine Güte, werd' doch mal 
konkret. Beschreib doch einfach ein Gefahrenszenario, das dadurch 
entstehen soll, statt auf den Boden zu stampfen und Fragen wie "merkt 
ihr's nicht" zu stellen. Nein, ich merke es nicht, was möglicherweise 
allerdings auch daran liegen könnte, daß Du beharrlich verschweigst, was 
es denn da zu merken gäbe.

> Damit, dass Aufrufe via ›sudo‹ ja einwandfrei nachprüfbar
> geloggt würden? Seht ihr echt nicht, dass es lediglich ein Aufruf von
> ›sudo‹ in dieser kaputten Konfiguration ist, um das alles auszuhebeln?
> Dass genau das das Problem dieser Konfiguration ist?

Auch ein weiteres Aufstampfen und Iterieren Deiner unsinnigen 
Behauptung, daß das "kaputt" sei, ist zwar lustig für mich und unsere 
Mitleser, aber leider immer noch weit von einem sachlichen Argument 
entfernt. Behaupten kannst Du viel, argumentativ belegen oder gar 
überzeugen aber nichts.

> Ja … weil das natürlich in einem C&P-String nie auftauchen kann, und in
> Scripten selbstverständlich auch nicht. Is klar …

Also ist die Standardkonfiguration von sudo(8) doof, weil Vollhonks 
Sachen in ihrer Shell ausführen, die sie nicht verstanden haben? Meine 
Güte, was für eine unfaßbar riesige Sicherheitslücke, da hat su(1) ja 
echt den total tollen Vorteil, daß die Vollhonks HAARGENAU EXAKT 
DASSELBE UNVERSTANDENE ZEUGS DANN DIREKT IN IHRE GOTTVERDAMMTE ROOT-SHEL 
EINTIPPEN!

Verstehst Du das? Die wollen einfach nur ein vorhandenes oder 
eingebildetes Problem lösen, und sie sind so dermaßen erpicht darauf, 
daß sie alle nötige und sinnvolle Vorsicht über Bord werfen! Und daran 
ändern Du und ich nichts, weder mit einer anderen Software wie su(1), 
noch mit einer anderen Konfiguration von sudo(8). In der IT gibt es 
deswegen nicht von ungefähr den bekannten Spruch "immer, wenn Du etwas 
idiotensicher gemacht hast, kommt die Natur und erfindet größere 
Idioten".

Ich weiß auch nicht, was für ein merkwürdiges Verständnis von Sicherheit 
zu einer solchen Argumentation kommt und wie weit sie dann geht. 
Womöglich wäre es das Sicherste (tm), wenn Privilegienerhöhung gar nicht 
möglich wäre. Das wäre jedenfalls die logische Konsequenz.

> Ein T. schrieb:
>> Zudem bemerkt hat Sheeva ja sehr schön beschrieben, daß
>> Linux kompetente Benutzer voraussetzt,
>
> Deiner Ansicht nach richtet sich Buntu [...] also an kompetente Linuxnutzer.

Du mußt wirklich aufmerksamer lesen, Jack. Ich schrieb "Linux", weil ich 
alle Linuxe gemeint habe, und zwar, ja, auch die Ubuntus. Die machen die 
Sache ein bisschen einfacher, aber auch sie setzen mündige, kompetente 
Nutzer voraus.

> Bist du denn auch einer dieser …
> „kompetenten“ Linuxnutzer, für die Buntu geschaffen wurde? Das würde in
> der Tat einiges erklären …
>
> OT: kennst du das Geheimnis, das hinter dem „Bearbeiten“-Link unter
> einem Beitrag steht? Ist spannend: man sieht nicht so dämlich aus, wie
> wenn man für eine Antwort drei Beiträge schreibt.

Aha, dann sind wir also jetzt schon auf der Ebene persönlicher Angriffe 
und Provokationen angekommen. Daß Du das nötig zu haben scheinst, 
erhärtet meinen Verdacht, daß Du entweder keine sachlichen Argumente 
hast oder es warum auch immer nicht schaffst, sie zu formulieren und 
vorzubringen.

Schau, wenn Du keine Argumente hast, dann halt Dich doch einfach mit 
Deinem FUD bezüglich einer angeblich unsicheren Konfiguration zurück und 
erspar uns und den Anwesenden solche unsinnigen Diskussionen.

> In meiner Welt, die ich für recht real halte, benötigt ein kompetenter
> Linuxnutzer die kaputte Konfiguration nicht als Krücke, sondern er
> richtet sich sein ›sudo‹ direkt passend und sicher ein. Er ist ja
> schließlich kompetent.

Das stimmt, und deswegen ändere ich auch etwas an meiner 
sudo-Konfiguration: ich trage meinen Benutzer mit visudo(8) in die 
sudoers(5) ein, denn mitunter bearbeite ich die Gruppenzugehörigkeiten 
meines Benutzers und möchte dadurch verhindern, mich selbst 
auszuschließen, wenn meine Software oder ich dabei möglicherweise die 
Gruppen "sudo" und "admin" vergessen sollten.

Am Credential Caching dagegen ändere ich ganz bewußt nichts, weil ich 
das (siehe oben) für ein sehr sinnvolles Feature halte und deswegen 
keinen Grund dafür sehe, dessen Standardkonfiguration zu ändern. Das ist 
gleichermaßen sicher wie in mehrerlei Hinsicht komfortabel.

Und ja, eine moderne Sicht auf das Thema Sicherheit berücksichtigt auch 
den Komfort für die Nutzer. Denn deren Arbeit mit Verweis auf die 
Sicherheit zu erschweren, senkt deren Akzeptanz von Sicherheitsmaßnahmen 
und fördert ihre Bereitschaft, die Sicherheitsmaßnahmen kreativ zu 
umgehen, was am Ende viel schlimmere Auswirkungen auf das 
Sicherheitsniveau (siehe dazu auch oben bei "Paßwortlänge") haben kann 
als alles, was zuvor verhindert werden sollte.

Beitrag #7658911 wurde von einem Moderator gelöscht.
Beitrag #7658918 wurde von einem Moderator gelöscht.
Beitrag #7658946 wurde von einem Moderator gelöscht.
Beitrag #7658959 wurde von einem Moderator gelöscht.
Beitrag #7658965 wurde von einem Moderator gelöscht.
Beitrag #7658966 wurde von einem Moderator gelöscht.
Beitrag #7658998 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.