PATH Problem

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

PATH Problem

Beitrag von schwedenmann » 02.08.2018 16:37:13

Hallo

Habe seit einigen Tagen auf mehreren unstable-Installationen (amd64 + i686, Kernel 4.17.0-1) ein PATH Problem. Außert sich z.B. darin, das ich nichts mehr per apt installieren kann, oder das das simple shutdown -r now nicht mehr funktioniert.

Fehlermeldung bei apt-get
root@duron1800:/home/joerg# apt-get dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
g++-7 libargon2-0 libdns-export1100 libstdc++-7-dev linux-headers-4.16.0-1-common linux-kbuild-4.16
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Die folgenden Pakete werden aktualisiert (Upgrade):
apparmor bind9-host dictionaries-common emacsen-common grub-common grub-pc grub-pc-bin grub2-common gzip libapparmor1 libbind9-160 libcryptsetup12
libdns-export1102 libdns1102 libidn2-0 libisc-export169 libisc169 libisccc160 libisccfg160 liblwres160 man-db
21 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 659 kB von 11,1 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 49,2 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 http://192.168.178.30:3142/ftp.de.debian.org/debian unstable/main i386 apparmor i386 2.13-8 [566 kB]
Holen:2 http://192.168.178.30:3142/ftp.de.debian.org/debian unstable/main i386 libapparmor1 i386 2.13-8 [92,9 kB]
Es wurden 659 kB in 0 s geholt (3.508 kB/s).
Changelogs werden gelesen... Fertig
Vorkonfiguration der Pakete ...
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
E: Sub-process /usr/bin/dpkg returned an error code (2)
PATH als root
root@duron1800:/home/joerg# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

/etc/profile
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH

if [ "${PS1-}" ]; then
if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
# The file bash.bashrc already sets the default PS1.
# PS1='\h:\w\$ '
if [ -f /etc/bash.bashrc ]; then
. /etc/bash.bashrc
fi
else
if [ "`id -u`" -eq 0 ]; then
PS1='# '
else
PS1='$ '
fi
fi
fi

if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi
Wenn ich jetzt manuell den Pfad setze: #PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin geht es natürlich wieder (ich meine apt-get), incl. shutdown.

systemctl poweroff dagegen funktioniert, ohne das obige PATH-Setzen :!:

Was ist da los, auf einem aktuellen Arch, kernel 4.17-10 oder schon 12) gibt es derartige Probleme nicht.

mfg
schwedenmann

tobo
Beiträge: 1964
Registriert: 10.12.2008 10:51:41

Re: PATH Problem

Beitrag von tobo » 02.08.2018 17:55:26

PATH wird nicht oder falsch gesetzt - die sbin-Pfade fehlen.
Macht es einen Unterschied, ob du mit "su" oder mit "su -" zu root wirst? In der Annahme, dass du nicht "su -p" oder "su -m" aufrufst, was steht denn in /etc/login.defs hinter ENV_SUPATH? Und was ist, wenn du mit STRG-ALT-Fn auf die Konsole wechselst und dich direkt als root anmeldest?

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: PATH Problem

Beitrag von schwedenmann » 02.08.2018 18:20:23

Hallo
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
mfg
schwedenmann

ich mach im Moment nur in der Konsole su + retrun und dann das Rootpw

mfg
schwedenmann

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: PATH Problem

Beitrag von KP97 » 02.08.2018 18:43:22

Verursacher ist ein Fehler in der Version 2.32-0.3 von util-linux.
Evtl. wird das ja schnell behoben, bis dahin kann man aber in der .bashrc die folgenden Zeilen hinzufügen:

Code: Alles auswählen

export PATH=$PATH:/sbin
export PATH=$PATH:/usr/sbin
export PATH=$PATH:/usr/local/sbin

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PATH Problem

Beitrag von Blackbox » 04.08.2018 16:02:03

Das ist kein Fehler, sondern gewollter Posixstandard!

Lösung steht hier: viewtopic.php?f=12&t=170288&p=1180596#p1180596

Und bitte lasst dieses Variablem Export Gefrickel, oder baut dieses zurück!
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: PATH Problem

Beitrag von KP97 » 04.08.2018 16:07:39

Blackbox hat geschrieben: ↑ zum Beitrag ↑
04.08.2018 16:02:03
Und bitte lasst dieses Variablem Export Gefrickel, oder baut dieses zurück!
Mein System konfiguriere ich selbst...wie bereits erwähnt...

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PATH Problem

Beitrag von Blackbox » 04.08.2018 18:49:25

KP97 hat geschrieben: ↑ zum Beitrag ↑
04.08.2018 16:07:39
Mein System konfiguriere ich selbst...wie bereits erwähnt...
Hat niemand etwas dagegen! - Die Frage ist doch eher ob du in diesem Fall "konfigurieren" musst? - Aber wie gesagt, dein System, dein Ding!
Auch wenn ich befürchte, dass du dir eine veritable Sicherheitslücke gebaut hast.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: PATH Problem

Beitrag von schwedenmann » 05.08.2018 07:49:17

Hallo

@Blackbox
Die Lösung ist doch ganz einfach!
Anstatt wie bisher das ($SHELL) Environment des Benutzers zu verwenden, verwenden wir ab sofort das Environment von Root!
das ist aber mal wieder typisch Debiangefrickel.

Bei Freebsd geht su, bei Arch geht su , bei centOS mit Sicherheit auch ohne su - also was soll der Blödsinn.


mfg
schwedenmann

Benutzeravatar
Teddybear
Beiträge: 3163
Registriert: 07.05.2005 13:52:55
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Altomünster
Kontaktdaten:

Re: PATH Problem

Beitrag von Teddybear » 05.08.2018 09:28:36

util-linux (2.32-0.4) unstable; urgency=medium

The util-linux implementation of /bin/su is now used, replacing the
one previously supplied by src:shadow (shipped in login package), and
bringing Debian in line with other modern distributions. The two
implementations are very similar but have some minor differences (and
there might be more that was not yet noticed ofcourse), e.g.

- new 'su' (with no args, i.e. when preserving the environment) also
preserves PATH and IFS, while old su would always reset PATH and IFS
even in 'preserve environment' mode.
- su '' (empty user string) used to give root, but now returns an error.
- previously su only had one pam config, but now 'su -' is configured
separately in /etc/pam.d/su-l

The first difference is probably the most user visible one. Doing
plain 'su' is a really bad idea for many reasons, so using 'su -' is
strongly recommended to always get a newly set up environment similar
to a normal login. If you want to restore behaviour more similar to
the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.


-- Andreas Henriksson <andreas@fatal.se> Fri, 03 Aug 2018 10:52:22 +0200
Versuchungen sollte man nachgeben. Wer weiß, ob sie wiederkommen!
Oscar Wilde

Mod-Voice / My Voice

owl102

Re: PATH Problem

Beitrag von owl102 » 05.08.2018 10:30:07

schwedenmann hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 07:49:17
Bei Freebsd geht su, bei Arch geht su , bei centOS mit Sicherheit auch ohne su - also was soll der Blödsinn.
Fedora hat schon länger das für Debian neue Verhalten.

Die Auswirkungen sind dort aber subtiler, da /usr/sbin auch im PATH eines normalen Benutzers steckt:

Code: Alles auswählen

[owl102@fedora28 ~]$ echo $PATH
/usr/share/Modules/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/owl102/.local/bin:/home/owl102/bin
Der dazugehörige Ausschnitt aus /etc/profile:

Code: Alles auswählen

# Path manipulation
if [ "$EUID" = "0" ]; then
    pathmunge /usr/sbin
    pathmunge /usr/local/sbin
else
    pathmunge /usr/local/sbin after
    pathmunge /usr/sbin after
fi
(Die Funktion pathmunge ist lokal in /etc/profile definiert.)

PATH nach su:

Code: Alles auswählen

/usr/share/Modules/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/owl102/.local/bin:/home/owl102/bin
PATH nach su -:

Code: Alles auswählen

/usr/share/Modules/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

KP97
Beiträge: 3403
Registriert: 01.02.2013 15:07:36

Re: PATH Problem

Beitrag von KP97 » 05.08.2018 13:35:49

owl102 hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 10:30:07
Fedora hat schon länger das für Debian neue Verhalten.
Die Auswirkungen sind dort aber subtiler, da /usr/sbin auch im PATH eines normalen Benutzers steckt:

Code: Alles auswählen

[owl102@fedora28 ~]$ echo $PATH
/usr/share/Modules/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/owl102/.local/bin:/home/owl102/bin
Wenn man @Blackbox Glauben schenken soll, hat sich RedHat da aber eine veritable Sicherheitslücke geleistet...na so was, sollte man denen mal mitteilen...

owl102

Re: PATH Problem

Beitrag von owl102 » 05.08.2018 13:57:58

KP97 hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 13:35:49
Wenn man @Blackbox Glauben schenken soll, hat sich RedHat da aber eine veritable Sicherheitslücke geleistet...na so was, sollte man denen mal mitteilen...
Das ist schon seit einem gefühlten Jahrzehnt so...

Ich bin jetzt neugierig geworden und habe mal etwas recherchiert, und dabei das gefunden: https://fedoraproject.org/wiki/Features/SbinSanity

Eingeführt wurde dies mit Fedora 10 im Jahre 2008.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PATH Problem

Beitrag von Blackbox » 05.08.2018 16:56:56

KP97 hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 13:35:49
Wenn man @Blackbox Glauben schenken soll, hat sich RedHat da aber eine veritable Sicherheitslücke geleistet...na so was, sollte man denen mal mitteilen...
Du sollst nicht mir irgendeinen »Glauben« schenken, sondern darüber nachdenken, warum wohl dieser Ansatz so bei Debian implementiert wurde.

Schade, wenn man von sich so überzeugt ist und die eigene Borniertheit nicht mehr von Wissen unterscheiden kann. - Und natürlich bist du schlauer, als alle Entwickler und Maintainer dieser Welt, die den Posixstandard (wahrscheinlich) umsetzten, weil ihnen gerade langweilig war.
@KP97 Von mir aus kannst du dein Gefrickel gern beibehalten, ist doch - wie erwähnt - dein System.
Ich für meinen Teil werde den implementierten Posixstandard nutzen, der ist sicher und auf vielen unixoiden Systemen und bereits seit Jahrzehnten erprobt.
$JEDER nach Belieben ...

Mehr muss dazu nicht gesagt werden.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: PATH Problem

Beitrag von dufty2 » 05.08.2018 19:27:31

Mmmh, wär' mir nicht mal aufgefallen ;)
Denn ich mach das immer so.
Also "su -" statt "su" allein, schon seit Jahren. Ob Posix-Standard oder nicht.
Kenn' das gar nicht anders.

Hoffentlich habe ich es in all meinen Posts hier auch so angegeben :)

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: PATH Problem

Beitrag von Blackbox » 05.08.2018 19:51:36

dufty2 hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 19:27:31
Also "su -" statt "su" allein, schon seit Jahren. Ob Posix-Standard oder nicht.
Hallo duffy2,
hier liegt ein Missverständnis vor.
Nicht ist der Posixstandard, sondern dass Root auch sein eigenes Environment nutzt.
Bisher hat Root (su) in Debian das Environment des Benutzers verwendet, aus dessen Account, su aufgerufen wurde.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: PATH Problem

Beitrag von dufty2 » 05.08.2018 20:04:40

Blackbox hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 19:51:36
dufty2 hat geschrieben: ↑ zum Beitrag ↑
05.08.2018 19:27:31
Also "su -" statt "su" allein, schon seit Jahren. Ob Posix-Standard oder nicht.
Hallo duffy2,
hier liegt ein Missverständnis vor.
Die technische Details sind mir letztendlich schnuppe ;)
Mir geht es darum, dass ich das gleiche Environment vorfinde
wie wenn ich mich auf der (virtuellen) Konsole (login: resp. Password:) einlogge:
Daher stets
su -
bzw.
su - user

Nicht mehr, nicht weniger :)

Antworten