Buster. Keine updates möglich

[geier22]

Also ganz kurz. was muss ich tun damit der Pfad stimmt.

Wie schon mehrmals gesagt:
https://de.wikipedia.org/wiki/Su_(Unix):

Die Syntax ist su benutzername. Ohne Angabe eines Benutzernamens wechselt su nach einer Passwortabfrage zum Benutzer root. su - oder su -l simulieren einen kompletten Login-Vorgang, d. h., es werden das komplette Profil des neuen Benutzers eingelesen und die Umgebungsvariablen neu gesetzt.

Konsole:

statt su

su -

eingeben.

Zumindest in Xfce / Gnome geht das z.B. mit Synaptic weiterhin als wäre nicht gewesen. Also Synapiic aufrufen PW eingeben und gut.

[Ellison]

Zumindest in Xfce / Gnome geht das z.B. mit Synaptic weiterhin als wäre nicht gewesen. Also Synapiic aufrufen PW eingeben und gut.

KDE auch.

[geier22]

uaaahhhh-- Bin grad Opfer dieses vermaledeiten su - geworden
Aktion: LO von LO installieren.
Sieht dann so aus
Elegant wie immer aus dem Dateimanager heraus: Terminal in diesem Verzeichnis öffnen:

Code: Alles auswählen

hans@sparkyxfce:/media/cinnamonhome/hans/Downloads/LibreOffice_6.1.0.3_Linux_x86-64_deb/DEBS$ su
Passwort: 
root@sparkyxfce:/media/cinnamonhome/hans/Downloads/LibreOffice_6.1.0.3_Linux_x86-64_deb/DEBS# dpkg -i *.deb
dpkg: Warnung: »ldconfig« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Warnung: »start-stop-daemon« wurde im PATH nicht gefunden oder ist nicht ausführbar
dpkg: Fehler: 2 erwartete Programme nicht im PATH gefunden oder nicht ausführbar
Beachten Sie: PATH von root sollte normalerweise /usr/local/sbin, /usr/sbin und /sbin enthalten

Also raus und mit su - wieder rein
Mist - jetzt bin ich im Root - Verzeichniss
Also cd .. bla . bla
und jetzt darf ich installieren

Fazit:
Terminal in einem Verzeichnis über den Dateimanager öffnen, um als root darin herumzupfuschen ist ein sinnloses Feature geworden.

Edit:
Um aus dem Dateimanager heraus wie gewohnt arbeiten zu können werde ich wohl der Empfehlung folgen:

If you want to restore behaviour more similar to
the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

Ist die Syntax eigentlich so richtig?

Code: Alles auswählen

ALWAYS_SET_PATH yes

[Emess]

Fazit:
Terminal in einem Verzeichnis über den Dateimanager öffnen, um als root darin herumzupfuschen ist ein sinnloses Feature geworden.

so sieht es nämlich aus.
su - ist nicht die Lösung . Den pfad müsste man anpassen, wenn man denn wüsste wie?

[geier22]

su - ist nicht die Lösung . Den pfad müsste man anpassen, wenn man denn wüsste wie?

Edit:
Um aus dem Dateimanager heraus wie gewohnt arbeiten zu können werde ich wohl der Empfehlung folgen:

If you want to restore behaviour more similar to
the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

Ist die Syntax eigentlich so richtig?

Code: Alles auswählen

ALWAYS_SET_PATH yes

[geier22]

yepp - funktioniert
habe es da eingefügt (als su - )

Code: Alles auswählen

# *REQUIRED*  The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH	PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH	PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
ALWAYS_SET_PATH yes

Update ganz normal möglich

Meine benutzerdefinierten Aktionen in Thunar (Datei als Root mit Nano / Mousepad) usw funktionieren auch wieder.

Listening to: 'Early Sunday Mornin'' from 'Blues By Request' by 'Brother Yusef' with JRiver Media Center 24

[Emess]

Dann schmeiß ich mal den Riemen auf Buster und probier das mal

[Emess]

geklappt

[Blackbox]

also

Code: Alles auswählen

su -

was genau bewirkt das? Probier ich nacher auf jedenfall aus.
Aber das wird ja nicht die endlösung sein?

Wenn du dir die Mühe machen würdest, den verlinkten Thread [1] durchzulesen, dann wirst du auch eine Erklärung finden, warum es diese Änderung in Debian gab.
Warum versuchen alle hier diese Variablen-Gefrickel?
Euch ist hoffentlich klar, dass ihr mit diesem Variablen-Gefrickel, die eingeführten Änderungen - die auch wegen Sicherheitsbedenken - der Installation von util-linux Version 2.32.1 aushebelt und euch so eine Sicherheitslücke in euer System eingebaut?

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

[1] viewtopic.php?f=12&t=170288&start=15#p1180596

[MSfree]

Euch ist hoffentlich klar, dass ihr mit diesem Variablen-Gefrickel, die eingeführten Änderungen - die auch wegen Sicherheitsbedenken - der Installation von util-linux Version 2.32.1 aushebelt und euch so eine Sicherheitslücke in euer System eingebaut?

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. Ausserdem habe ich weiter obern schon geschrieben, daß eine Umgebungsvariable, die zu einer Sicherheitslücke wird, nicht dadurch entschärtf wird, indem man sie nicht setzt. Als root kann ich die nämlich auch manuell auf der Kommandozeile setzen. Das System wird dadurch also kein Stück sicherer.

Insofern ist das, was du als "Variablen-Gefrickel" völlig legitim und erzeugt keine zusätzliche Sicherheitslücke. Es ist nur unbequem, weil man sich nun bei jeder Neuinstallation an dieses "Variablen-Gefrickel" erinnern muß und von der ach so supersicheren Vorgabe umstellen muß.

[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