Artikel mit Tag shells
Verwandte Tags
bash cracker debian event not found exit-status exploit extglob fortune logfiles login-shell looser passwort posix rants root shadow shopt standard utmp zsh dummuser crontab irc k-line kickban openbsd vipw gnu screen 4.4 admins akismet apache awk bsd.port.mk checksum cksum current cvs df faq flavors freebsd ftp gentoo gnaaa hamburg howto job make mirror netbsd pakete patch php pkg_add pkg_info ports ps qmail repos sqlite stable testrechner update wheezy youtube zooomr adduser ftp-user package useradd vsftpd/bin/sh-Skripte == Plattformunabhaengig?
Submitted by Christian Schneider on Mo, 2007-10- 1 02:09
Sowas bekomme ich in letzter Zeit desoefteren zu hoeren, aber das ist nicht zwingend korrekt. Fakt ist, dass /bin/sh auf jedem Unix eine zu IEEE Std 1003.1 konforme Shell ist. Ein Shellscript das
Zuerst kommt es darauf an wie man "Plattformunabhaengig" definiert. So wie Wikipedia es tut oder so, dass es ohne Aenderungen auf jedem System ohne Anpassungen funktioniert?! Es gibt u. a. im Usenet einige Luegner, die behaupten das es Unices ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. Ein Unix ohne /bin/sh ist kaputt! Ganz einfach. Bei den meisten Linuxdistributionen ist es ein "Quasistandard", dass /bin/sh ein Symlink auf die GNU Bash ist, aber das wars dann auch schon wieder. Unter *BSD ist /bin/sh eine PD-KSH wie man hier sehen kann
// edit
Oben habe ich geschrieben das ein Unix ohne /bin/sh kaputt ist und das ist auch korrekt. Einige Luegner (u. a. im Usenet) behaupten zwar nach wie vor das es Systeme ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. /bin/sh zeigt immer auf eine zu POSIX konforme Shell. Wenn das nicht der Fall ist, wurde das manuell geaendert.
Ich lasse mich aber gerne ueberzeugen und mir ein Unix nennen, dass ohne /bin/sh laeuft.
#!/bin/sh als Interpreter hat, wird auf jedem Unix (AIX, *BSD, SunOS, Linux, ..) korrekt gestartet und jetzt unterscheiden sich die Geister.Zuerst kommt es darauf an wie man "Plattformunabhaengig" definiert. So wie Wikipedia es tut oder so, dass es ohne Aenderungen auf jedem System ohne Anpassungen funktioniert?! Es gibt u. a. im Usenet einige Luegner, die behaupten das es Unices ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. Ein Unix ohne /bin/sh ist kaputt! Ganz einfach. Bei den meisten Linuxdistributionen ist es ein "Quasistandard", dass /bin/sh ein Symlink auf die GNU Bash ist, aber das wars dann auch schon wieder. Unter *BSD ist /bin/sh eine PD-KSH wie man hier sehen kann
# uname -rsEs spricht auch nichts dagegen wenn man Shellscripte schreibt, die eine bestimmte Shell voraussetzen, allerdings sollte man sich ueberlegen ob es zwingend notwendig ist das Script so zu schreiben.
OpenBSD 4.2
# strings /bin/sh | grep KSH
KSH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
// edit
Oben habe ich geschrieben das ein Unix ohne /bin/sh kaputt ist und das ist auch korrekt. Einige Luegner (u. a. im Usenet) behaupten zwar nach wie vor das es Systeme ohne /bin/sh gibt, aber das ist schlicht und einfach falsch. /bin/sh zeigt immer auf eine zu POSIX konforme Shell. Wenn das nicht der Fall ist, wurde das manuell geaendert.
Ich lasse mich aber gerne ueberzeugen und mir ein Unix nennen, dass ohne /bin/sh laeuft.
"root hat doch eine Shell!?"
Submitted by Christian Schneider on Mo, 2007-09- 3 08:19
Heute musste ich kurz zu $FIRMA, weil diese Probleme mit Logins auf einem Server hatten, den ich erst vor kurzem aufgesetzt hatte. Das innerhalb der ersten zwei Minuten ~10 Mal "Ich hab wirklich nichts daran geaendert!" kam, muss ich nicht extra erwaehnen oder? Der "Hauptadmin" war letzte Woche nicht da, so dass sein Stellvertreter (21 Jahre und Sohn eines Anzugtraegers) seine Unfaehigkeit am Server unter Beweis stellen konnte. $FIRMA wollte das bestimmte lokale User keine richtige Loginshell mehr haben, damit diese nicht auf die Idee kommen, sich via ssh(1) einzuloggen, sondern brav mit ftp(1) arbeiten. Normalerweise kein Problem.
Der stellv. Admin war naemlich mit vipw(8) ueberfordert; das ist per Default bei OpenBSD naemlich vi(1). nvi(1) um genau zu sein; also nicht so komfortabel wie Vim. Nachdem er versucht hat (Betonung liegt auf "versucht") die Loginshells fuer die User zu aendern, enthielt die /etc/passwd ploetzlich Zeilen wie :q!^I, exit und was weiss ich noch alles. Ausserdem hat er fuer root /bin/bash als Shell angegeben. Kann man ja auch machen, allerdings sollte man dabei zwei Sachen beruecksichtigen:
1.) $PORTSDIR/shells/bash muss installiert sein und
2.) /usr/local/bin/bash muss in der /etc/shells stehen.
Abgebrueht ist er aber schon irgendwie. Den Scheiss hat er am Donnerstag fabriziert, sich am Freitag nicht mehr darum gekuemmert und ist dann in aller Seelenruhe ins Wochenende gefahren. Der Admin hat ihn heute mit blutunterlaufenen Augen angesehen und war kurz davor ihn zu lynchen, weil der Server vier Tage unbrauchbar war und laut den Logfiles knapp 8000 fehlgeschlagene Logins verzeichnet waren. Nachdem $OBERCHEF angetrabt kam und ich ihm erklaert habe was - und wie es - passiert ist, bezweifle ich ernsthaft das der stellv. Admin noch laenger in dieser Firma taetig ist. Ich geh jetzt erstmal ins Internetcafé und trink 'n Cappuccino.
Ich liebe solche Montage. Ehrlich!
vipw als root, /bin/false fuer alle User die es betrifft und der Fall hat sich. Ganz einfach.. theoretisch zumindest.Der stellv. Admin war naemlich mit vipw(8) ueberfordert; das ist per Default bei OpenBSD naemlich vi(1). nvi(1) um genau zu sein; also nicht so komfortabel wie Vim. Nachdem er versucht hat (Betonung liegt auf "versucht") die Loginshells fuer die User zu aendern, enthielt die /etc/passwd ploetzlich Zeilen wie :q!^I, exit und was weiss ich noch alles. Ausserdem hat er fuer root /bin/bash als Shell angegeben. Kann man ja auch machen, allerdings sollte man dabei zwei Sachen beruecksichtigen:
1.) $PORTSDIR/shells/bash muss installiert sein und
2.) /usr/local/bin/bash muss in der /etc/shells stehen.
Abgebrueht ist er aber schon irgendwie. Den Scheiss hat er am Donnerstag fabriziert, sich am Freitag nicht mehr darum gekuemmert und ist dann in aller Seelenruhe ins Wochenende gefahren. Der Admin hat ihn heute mit blutunterlaufenen Augen angesehen und war kurz davor ihn zu lynchen, weil der Server vier Tage unbrauchbar war und laut den Logfiles knapp 8000 fehlgeschlagene Logins verzeichnet waren. Nachdem $OBERCHEF angetrabt kam und ich ihm erklaert habe was - und wie es - passiert ist, bezweifle ich ernsthaft das der stellv. Admin noch laenger in dieser Firma taetig ist. Ich geh jetzt erstmal ins Internetcafé und trink 'n Cappuccino.
Ich liebe solche Montage. Ehrlich!













Last ten comments: