Buster. Keine updates möglich

[Emess]

Habe mir vorgestern buster per netinstall neu installiert. heute wollte ich mal schauen, probieren und rumprobieren.
Also die Installation ist nackt und frisch. Installiert habe ich als Desktop KDE.
Ganz Kurz ich kann keine updates machen. Weil:

Code: Alles auswählen

dpkg: warning: 'ldconfig' not found in PATH or not executable
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
dpkg: error: 2 expected programs not found in PATH or not executable
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)

Disese Thread viewtopic.php?f=12&t=170288&hilit=dpkg+fehler habe ich gefunden, Aber da gibt es ja auch keine Lösung

[owl102]

Disese Thread viewtopic.php?f=12&t=170288&hilit=dpkg+fehler habe ich gefunden, Aber da gibt es ja auch keine Lösung

Doch, da gibt es eine Lösung: Nicht

Code: Alles auswählen

su

verwenden, sondern

Code: Alles auswählen

su -

[Emess]

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?

[MaGe]

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

su -
das ist die endlösung.


gruss MaGe

[Emess]

das kann definitiv nicht die Endlösung sein,
Denn sobald ich grafisch (dolphin oder krusader als root ) eine Datei bearbeiten will klappt das definitiv nicht.
Ich habe nicht Lust jedes mal die Konsole zu bemühen und eine endlose Syntax einzugeben.
Bitte keine Diskussion über Sinn und Unsinn von root auf dem Desktop

[owl102]

das kann definitiv nicht die Endlösung sein

Dann passe doch deinen PATH an und verwende weiterhin "su". (Wo der Unterschied zu "su -" ist und wo das eigentliche Problem steckt, das steht alles in dem von dir verlinkten Thread bzw. in den anderen Threads zu dem Thema, wie zum Beispiel viewtopic.php?f=27&t=170432 .)

Denn sobald ich grafisch (dolphin oder krusader als root ) eine Datei bearbeiten will klappt das definitiv nicht.

Was hat das damit zu tun? Der Zusammenhang zwischen "ldconfig und co. sind nicht im PATH des Benutzers" und "graphisch eine Datei als root bearbeiten" ist mir nicht klar.

[MSfree]

das kann definitiv nicht die Endlösung sein,

Offensichtlich fehlt doch nur /sbin in der PATH Umgebungsvariable.

PATH wird abhängig vom Benutzer individuell eingestellt. Dazu gibt es unter /etc die Dateien profile, bash.bashrc, die beim Login, su und sudo geladen werden. Außerdem gibt es unter /etc/skel die Dateien .profile und .bashrc, die beim Anlegen eines Benutzers in das Home-verzeichnis kopiert werden. Im Home gibt es folglich die Dateien .bashrc und .profile, die man als Benutzer individualisieren kann.

Die Entwickler haben nun in Testing und/oder SID einen Fehler in einer oder mehrere der o.g. Dateien eingebaut, so daß root keinen PATH auf /sbin mehr hat.

Das ist meiner Meinung nach ein Bug, den du melden könntest, mit Lösungsvorschlag, wenn du dazu Lust hast.

[owl102]

Das ist meiner Meinung nach ein Bug

Das ist eine ganz bewusst getätigte Änderung, die in anderen Distributionen schon länger vollzogen wurde. Siehe auch: viewtopic.php?p=1180632#p1180632

[Emess]

Das ist eine ganz bewusst getätigte Änderung, die in anderen Distributionen schon länger vollzogen wurde. Siehe auch: viewtopic.php?p=1180632#p1180632

Das glaub ich nicht, owl!
Wer gibt denn ganz Bewusst Instalationsmedien heraus und verhindert dass der Normaluser updates bzw. überhaupt irgendwas installieren kann?

[MSfree]

Das ist eine ganz bewusst getätigte Änderung,

Ich habe keine Lust und Zeit, den Thread und all seine Links in allen Einzelheiten nachzuvollziehen. Mir fiel nur auf, daß die PATH-Variable wohl aus eine Sicherheitsgrund nun irgendwie anders gesetzt wird. Was für ein Blödsinn. Seit wann führt eine PATH-Variable zu einer Sicherheitslücke?

Wenn bestimmte Verzeichnisse nicht im PATH stehen, wird dort eben nicht nach Executables gesucht. Das verhindert jedoch nicht, daß man solche Executables mit absolutem Dateinamen aufruft, was die Sicherheitslücke, die so ein Executable möglicherweise hat, nicht behebt.

Wer versucht, Sicherheitslücken mittels Aussparung von PATH zu lösen, betreibt Security by Obscurity.

Mit anderen Worten, das Fehlen des /sbin-Pfads beim root-User ist ein Bug und nichts anderes.

[MaGe]

das kann definitiv nicht die Endlösung sein

zcat /usr/share/doc/util-linux/NEWS.Debian.gz

Übersetzt/Translator

[...] Der erste Unterschied ist wahrscheinlich der am meisten sichtbare. Tun
plain 'su' ist aus vielen Gründen eine wirklich schlechte Idee, also ist die Verwendung von 'su -'
wird dringend empfohlen, immer eine neu eingerichtete Umgebung ähnlich zu bekommen
zu einem normalen Login. Wenn Sie ein Verhalten wiederherstellen wollen, das dem von
den vorherigen können Sie'ALWAYS_SET_PATH yes' in /etc/login.defs hinzufügen.[...]

wen dir das nicht passt su -
kannst es ja Ändern


gruss MaGe

[owl102]

Das glaub ich nicht, owl!

Wem glaubst du nicht? Dem Debian-Maintainer des Paketes util-linux, der diese Änderung im Changelog begründet und dokumentiert hat? Oder den Maintainern der anderen Distributionen (RHEL, Fedora, ...), bei denen es schon länger genauso ist?

Wer gibt denn ganz Bewusst Instalationsmedien heraus und verhindert dass der Normaluser updates bzw. überhaupt irgendwas installieren kann?

Diesen Vorwurf von dir kann ich (auch) nicht nachvollziehen. Der Normaluser verwendet Gnome Software oder Apper oder Synaptic für Updates oder Installationen, und das klappt.

Der Poweruser hingegen sollte dazu in der Lage sein, den Unterschied zwischen "su" und "su -" zu verstehen, und ggf. /sbin in seinen PATH hinzuzufügen, oder aber /etc/login.defs zu editieren, wenn er das alte Verhalten (welches inkompatibel zu den meisten größeren Distributionen ist) behalten möchte.

[owl102]

Mit anderen Worten, das Fehlen des /sbin-Pfads beim root-User ist ein Bug und nichts anderes.

Beim root-User ist /sbin im PATH.

[eggy]

Wer gibt denn ganz Bewusst Instalationsmedien heraus und verhindert dass der Normaluser updates bzw. überhaupt irgendwas installieren kann?

Die Version für Normaluser ist stable.

Auf testing musst Du mit solchen (oder schwerwiegenderen) Problemen rechnen.

[Emess]

Also ganz kurz. was muss ich tun damit der Pfad stimmt.
Ich bin Desktopuser seit sarge. Dieses Problem hatte ich noch nie.

Die Version für Normaluser ist stable.

Auf testing musst Du mit solchen (oder schwerwiegenderen) Problemen rechnen.

Ich probier und teste mit meinen Möglichkeiten ja auch gerne.
Mit meinem echten System bin ich auch immer noch bei "jessie"

Mir hilft wenn ein Profi sagt mach "genau das!"

[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ß.