Buster. Keine updates möglich

[Emess]

Und übrigens, "Endlösung" ist ein sehr belastetes Wort, das ist dir/euch doch hoffentlich bekannt?

Darüber hatte ich jetzt nach vergangenen 80 jahren gar nicht mehr dran gedacht.
Hiermit distanziere ich mich außdrücklich von dem Sinn dieses unglücklich gewählten Wortes und oute mich überdies als Weltmensch ohne jeglichen nationalen Allüren.

Was ds su - angeht, gesteh ich die neue Philosophie tatsächlich nicht. Vieleicht sogar weil sie für meine Zwecke nichts taugt.

[DeletedUserReAsG]

Was genau ist denn dein Problem mit ›su -‹ statt su? Wenn man die Logik betrachtet, ist die „neue“ Verhaltensweise durchaus nachvollziehbar, und das vorherige Verhalten war unlogisch. Wenn’s nur die zwei Tastendrücke mehr sind, könntest du dir ja ein Alias setzen. Vielleicht sogar ›s='su - '‹ – dann wär’s sogar noch ein Tastendruck weniger, du könntest doppelt soviele su pro Minute absetzen! Wenn’s allerdings technische Hintergründe haben sollte, könntest du die mal benennen – dann kann man schauen, wie man’s wieder passend macht, ohne dass es bei Updates zurückgesetzt wird.

OT: Mich interessiert schon ’n bisschen, welche scheunentorgroße Sicherheitslücke man mit der Bearbeitung von PATH denn aufreißen würde – vielleicht mag Blackbox das etwas ausführen?

[Emess]

auf der Konsole macht das "-" wohl nichts aus. Aber versuch mal einen Dateimanager als root zu starten. Klar sowas macht man doch nicht mit Linux.
Ich aber aber nicht alle Pfade im Kopf und habe auch keine lust einen zweizeiler in die Konsole zu hämmern nur weil ich schnell mal die bootreihenfolge der installierten Systeme zu ändern. etc.

[DeletedUserReAsG]

Du meinst „Rechtsklick → als Root ausführen“ oder so? Dann etwas warten, bis der Maintainer des betreffenden Filemanagers sich auf die Änderung eingestellt hat. Sowas kann bei Testing nunmal ausdrücklich vorkommen – wenn du das nicht willst, einfach auf Stable wechseln, das ist im Gegensatz zu Testing für Nur-Anwender gedacht.

Oder meinst du, aus ’ner Shell heraus? Das funktioniert genauso, wie vorher – abgesehen von dem einen Zeichen mehr.

[geier22]

Was genau ist denn dein Problem mit ›su -‹ statt su?

Bin zwar nicht Emess aber schau mal ein paar Beiträge weiter oben :
viewtopic.php?t=170527&p=1181782#p1181714

OT: Mich interessiert schon ’n bisschen, welche scheunentorgroße Sicherheitslücke man mit der Bearbeitung von PATH denn aufreißen würde – vielleicht mag Blackbox das etwas ausführen?

Ist ja gar nicht OT----> Interessiert mich aber auch. Aber das wäre vielleicht ein extra Thread. Mir ist z.B. überhaupt nicht klar wie z.B. das Policy-Kit
und die ganzen "Actions" in /usr/share/polkit-1/actions/ sich dazu verhalten. Denn die brauchen ja doch wohl alle das "normale" su ?
Letztendlich ist das ja wohl auch der Grund, warum ich mit Synaptic ein Update fahren kann (ja wohl als su), in der Konsole aber die
komplette SU- Umgebung neu geladen werden muss.

[DeletedUserReAsG]

Bin zwar nicht Emess aber schau mal ein paar Beiträge weiter oben:

Ich seh’ da nun kein Problem, das ’nen Testing-User vor ernsthafte Probleme stellen sollte.

Was policy-kit und Co. angeht, glaube ich nicht, dass die das Binary ›su‹ aufrufen. Allenfalls nutzen sie ’ne Lib davon, und dann ist die Umgebung auch egal.

[KP97]

Nein, man baut sich keine zusätzliche Sicherheitslücke ein.
Ob ich mit su oder mit su - zum root werden, ist hier völlig egal. Als root bin ich sowieso die Sicherheitslücke, die das System übernehmen, verändern und vergiften kann.

@MSfree
Ich gebe Dir völlig Recht.
Als ich in meinen Beiträgen diese von @Blackbox erwähnte "veritable Sicherheitslücke" angezweifelt habe, wurde ich von diesem User als "borniert" beschimpft.
Eigentlich wollte ich das damals schon melden, habe dann aber davon abgesehen, da man das eh nicht ernst nehmen kann...

Die vom Maintainer erwähnte möglich Änderung in /etc/login.defs funktioniert zwar, erzeugt aber eine Meldung im Log

SID_A login[391]: unknown configuration item `ALWAYS_SET_PATH'

Das kann man zwar ignorieren, aber ich habe ungern solche Meldungen im Log, daher bleibe ich bei meiner Variante mit der .bashrc.

[MSfree]

...daher bleibe ich bei meiner Variante mit der .bashrc.

Wenn du es systemweit bevorzugst, kannst du auch die /etc/bash.bashrc anpassen.
Ich werfe da nach Neuinstallationen ohnehin jede Menge Zeug rein, von aliases bis zu augenfreundlicheren LS_COLORS und schönerem PS1.

[KP97]

Ja, das stimmt, habe ich teils auch schon gemacht.
Da ich für root und user aber unterschiedliche Farben nutze, bin ich doch wieder in der lokalen .bashrc gelandet.
Fand ich persönlich übersichtlicher....

[Emess]

Ich seh’ da nun kein Problem, das ’nen Testing-User vor ernsthafte Probleme stellen sollte.

Was policy-kit und Co. angeht, glaube ich nicht, dass die das Binary ›su‹ aufrufen. Allenfalls nutzen sie ’ne Lib davon, und dann ist die Umgebung auch egal.

Wisst ihr, auch DAUś wie ich lernen gerne. Deshalb darf ich auf testing testen was ich will. und wenn ich was nicht kapier frag ich hier die "Debian Götter", für die es keine ernshaften Probleme gibt

[geier22]

Ich seh’ da nun kein Problem, das ’nen Testing-User vor ernsthafte Probleme stellen sollte.

Wie du aus meinem Beitrag sehen kannst, hab ich das ja auch souverän gemeistert.
Die Frage bleibt aber trotzdem, welchen praktischen Nährwert diese Aktion hat, außer der, das man halt gezwungen wird, seine Zeit damit zu verbringen, iim Terminal herum zu hacken.
Schönste Blüten treibt das ja in KDE, wo man erstmal seinen halben Lebenslauf ins Terminal hacken darf, bevor einem erlaubt wird, eine Datei als Root mit Kate zu bearbeiten.

Apropos: Alle machen das mit su -

Fedora 28 nix is --> ganz normal su
Opensuse Leap 15 nix ist ---> ganz normal su
Ubuntu und Mint sowieso.
Wer es nicht glauben will:

Code: Alles auswählen

OpenSuse Leap15

~> $PATH
bash: /home/hans/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin: No such file or directory
hans@linux-c94g:~> su
Password: 
linux-c94g:/home/hans # $PATH
bash: /sbin:/bin:/usr/sbin:/usr/bin: No such file or directory
linux-c94g:/home/hans # su -
linux-c94g:~ # $PATH
-bash: /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin: No such file or directory


Fedora 28

[hans@localhost ~]$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/hans/.local/bin:/home/hans/bin: No such file or directory
[hans@localhost ~]$ su
Passwort: 
[root@localhost hans]# $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/hans/.local/bin:/home/hans/bin: No such file or directory
[root@localhost hans]# su -
[root@localhost ~]# $PATH
-bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin: No such file or directory
[root@localhost ~]#

Darf ich mal bescheiden fragen, wer "alle" ist, außer ein paar Nischen - Distros ?

[Ellison]

Schönste Blüten treibt das ja in KDE, wo man erstmal seinen halben Lebenslauf ins Terminal hacken darf, bevor einem erlaubt wird, eine Datei als Root mit Kate zu bearbeiten.

Die coolen Jungs machen sowas mit nano und das läuft sogar mit su und ohne bashrc Gebastel.

[geier22]

Die coolen Jungs machen sowas mit nano und das läuft sogar mit su und ohne bashrc Gebastel.

Nano ? Kenn ich nicht geht denn das mit nem Klick
Ich kenn nur das:

Code: Alles auswählen

<action>
	<icon>/usr/share/icons/Papirus/64x64/apps/terminator.svg</icon>
	<name>Datei als root mit nano</name>
	<unique-id>1528122488128112-1</unique-id>
	<command>pkexec tilix -x &apos;nano %F&apos;</command>
	<description></description>
	<patterns>*</patterns>
	<other-files/>
	<text-files/>
</action>

[Ellison]

Bin mir nicht ganz sicher, ob das ein Scherz ist, deswegen: Nimm dies, Schurke => https://www.nano-editor.org/

[geier22]

Nimm dies, Schurke => https://www.nano-editor.org/

Endlich mal was Substanzielles
Vielen vielen Dank

[owl102]

Fedora 28 nix is --> ganz normal su
Opensuse Leap 15 nix ist ---> ganz normal su
Ubuntu und Mint sowieso.

Das Verhalten bei Fedora und CentOS ist schon länger wie jetzt bei Debian Testing. Den Rest habe ich gerade nicht zur Hand.

Wer es nicht glauben will (Cent OS 7):

Code: Alles auswählen

$ echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/user/.local/bin:/home/user/bin
$ su
# echo $PATH
/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/user/.local/bin:/home/user/bin

Das hatte ich aber schon in diesem Thread oder in einem der verlinkten Threads geschrieben, aber vermutlich hast du die (noch) nicht gelesen.

BTW: Erbarmt sich ein Moderator und fügt die drei Threads zusammen?

Fedora 28

Code: Alles auswählen

[hans@localhost ~]$ $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/hans/.local/bin:/home/hans/bin: No such file or directory
[hans@localhost ~]$ su
Passwort: 
[root@localhost hans]# $PATH
bash: /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/hans/.local/bin:/home/hans/bin: No such file or directory
[root@localhost hans]# su -
[root@localhost ~]# $PATH
-bash: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin: No such file or directory
[root@localhost ~]#

Damit hast du doch deine eigene, obenstehende Aussage widerlegt. Unter Fedora 28 wird bei "su" die Umgebung inkl. PATH übernommen, bei "su -" hingegen wird sie neu gesetzt. Wie aktuell bei Debian Testing.

[geier22]

Damit hast du doch deine eigene, obenstehende Aussage widerlegt. Unter Fedora 28 wird bei "su" die Umgebung inkl. PATH übernommen, bei "su -" hingegen wird sie neu gesetzt. Wie aktuell bei Debian Testing.

Eben nicht. Ich kann als User / root mit einfachen su bei Debian weder installieren noch rebooten oder runter fahren.

Sowohl bei OpenSuse als auch bei Fedora ist dies möglich (reboot /shutdown) da $PATH alle Pfade beinhaltet.

Natürlich gibt es in jeder Distro auch su - (selbst bei Ubuntu). Die Frage ist doch aber wann und wozu muss ich das anwenden.

So jetzt lade ich mir auch noch CentOs runter.

[owl102]

Eben nicht.

Eben doch.

Ich kann als User / root mit einfachen su bei Debian weder installieren noch rebooten oder runter fahren.

Ja, weil /sbin bei Debian nicht im PATH eines normalen Benutzers enthalten ist, bei CentOS/Fedora aber schon, und zwar schon seit ca. 10 Jahren: viewtopic.php?p=1180658#p1180658

Sowohl bei OpenSuse als auch bei Fedora ist dies möglich da $PATH alle Pfade beinhaltet.

Bei Debian aber nun einmal nicht, und daran hat sich auch nichts geändert.

Was hat sich geändert: Früher wurde bei "su" und "su -" PATH neu gesetzt, aktuell ist dies nur noch bei "su -" der Fall. Genauso wie bei CentOS/Fedora.

Die Frage ist doch aber wann und wozu muss ich das anwenden.

Möchte man aktuelles Verzeichnis und Umgebungsvariablen (inkl. PATH) übernehmen, nimmt man "su". Möchte man das jedoch neu setzen, so als würde man sich als root einloggen, nimmt man "su -".

[DeletedUserReAsG]

Die Frage bleibt aber trotzdem, welchen praktischen Nährwert diese Aktion hat, […]

Es wird einfach ein Stück logischer und damit einsteigerfreundlicher in der Bedienung: ohne Loginshell: altes Environment wird beibehalten, Loginshell: Environment des Zielusers wird geladen.

[geier22]

Früher wurde bei "su" und "su -" PATH neu gesetzt, aktuell ist dies nur noch bei "su -" der Fall. Genauso wie bei CentOS/Fedora.

Da ist definitiv falsch.
Bei einfachen su wurde nie der Pfad neu gesetzt.
Es wäre sonst gar nicht möglich gewesen, ein Terminal über den Dateimanager in einem Verzeichnis zu öffnen, root zu werden und mit dpkg etwas
aus diesem Verzeichnis zu installieren. Das habe ich 100derte Male gemacht.
Jetzt geht das nicht mehr. Ich muss, um etwas zu installieren, mich mit su - einloggen und lande erstmal im Root- Verzeichnis.
um mich dann wieder hoch zu hangeln oder vorher den Dateipfad aus dem Dateimanager zu kopieren. Was ein Irrsinn

Selbst shutdown / reboot ist nur noch mit su - möglich.

Wozu ist su dann überhaupt noch da ??

So unterschiedlich wird das Gehandhabt:

Fedora:
Aus der Konsole shutdown / reboot als normaler User möglich

OpenSuse:
Aus der Konsole shutdown / reboot als su möglich

Debian
Aus der Konsole shutdown / reboot nur als su - möglich

[geier22]

Es wird einfach ein Stück logischer und damit einsteigerfreundlicher in der Bedienung: ohne Loginshell: altes Environment wird beibehalten, Loginshell: Environment des Zielusers wird geladen.

Jetzt habe wir aber 2 Varianten des su - oder gar mehrere Hab noch nicht alles getestet.
SU: Offensichtlich noch die Bearbeitung von Dateien möglich aber keine Installation (bzw alles, was in /sbin steht)
SU -: Installieren, update und was in sbin steht.

Was ist da einfacher? Das ist total inkonsistent und Verwirrend.
Noch ein kleines Grimmick am Rande:

Code: Alles auswählen

hans@sparkyxfce:~$ su -
Passwort: 
root@sparkyxfce:~# synaptic
Unable to init server: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt

(synaptic:1846): Gtk-WARNING **: 18:32:09.520: cannot open display: 
root@sparkyxfce:~# Abgemeldet
hans@sparkyxfce:~$ su
Passwort: 
root@sparkyxfce:/home/hans# synaptic  :mrgreen: 
root@sparkyxfce:/home/hans# 

[DeletedUserReAsG]

Wozu ist su dann überhaupt noch da?

su ist mitnichten ausschließlich dazu da, Root zu werden und auf Programme unter /sbin zuzugreifen. Es gibt übrigens auch Distris, da sieht’s so aus:

Code: Alles auswählen

lrwxrwxrwx   1 root root    7  5. Jan 2018  sbin -> usr/bin

Manchmal möchte man halt schnell was als anderer User erledigen, dabei aber das Environment des aufrufenden Users zur Verfügung haben (Library-Paths beim Bauen, etc.) – das geht nun. Leute, die’s aus Bequemlichkeitsgründen auf die alte, unlogische Art benutzt haben, müssen sich nun halt etwas umgewöhnen. Paketbauer müssen sich halt auch auf die Änderung einstellen – bis Testing Stable wird, werden sie’s schon noch auf die Reihe bekommen, da kann man ziemlich sicher von ausgehen. Und Einsteigern wird das „neue“ Verhalten deutlich sinnvoller erscheinen, weil eben nachvollziehbar. So what?

Kleine Anmerkung am Rande:

Noch ein kleines Grimmick am Rande:
[…]

Ja, so soll’s auch nicht genutzt werden. Im Gegenteil: das würde ich als „veritable Sicherheitslücke“ durchgehen lassen, wenn es ohne Weiteres ginge – vielleicht ist’s ja sogar die, von der die schwarze Schachtel geschrieben hat. Er hat sich ja leider noch nicht weiter dazu geäußert. Zumindest unter X ist’s wohl nicht zu schwierig, als User auf die von Root gestarteten Fensterprogramme zuzugreifen, wenn die unter dem xserver des Users laufen.

[schwedenmann]

Hallo

Ist dieses Verhalten jetzt normal und gewollt

als user: synaptic verweigert den Start
su - : synaptic verweigert den Start
su : synaptic startet

selbes Verhalten bei gparted

mfg
schwedenmann

[DeletedUserReAsG]

Vermutlich nicht, und vermutlich wird’s noch angepasst. Dauert halt je nach Aufwand noch etwas.

[owl102]

Früher wurde bei "su" und "su -" PATH neu gesetzt, aktuell ist dies nur noch bei "su -" der Fall. Genauso wie bei CentOS/Fedora.

Da ist definitiv falsch.
Bei einfachen su wurde nie der Pfad neu gesetzt.

Nicht der Verzeichnispfad, sondern die Umgebungsvariable PATH.

Mein Debian Stable ist folgender Meinung:

Code: Alles auswählen

$ more /etc/debian_version
9.4
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
$ su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Wie man sieht, setzt dort "su" PATH neu. Das macht Fedora/CentOS nicht und Debian Testing nun auch nicht mehr. *Das* ist die Änderung, die bei Debian Testing vollzogen wurde.

Ich muss, um etwas zu installieren, mich mit su - einloggen und lande erstmal im Root- Verzeichnis.
um mich dann wieder hoch zu hangeln oder vorher den Dateipfad aus dem Dateimanager zu kopieren. Was ein Irrsinn

Dann ändere das doch.

So unterschiedlich wird das Gehandhabt:

Aber nur, weil bei Fedora /sbin (seit 10 Jahren) per default im User-PATH steht, und bei Debian eben nicht, AFAIK noch nie.