Nebezpečné uninstall.sh

22.11.2013 18:58 | Přečteno: 1559× | Bash | poslední úprava: 25.11.2013 17:17

Podíváme se blíže na skript uninstall.sh, který šíří Princeton Instruments ve svém Picam_SDK-v2.6.0.run.

#!/bin/sh
# Default variables
START_DIR=`dirname $0`
START_DIR=`cd $START_DIR; pwd`
echo "Start_DIR is" $START_DIR

USR_LIB=/usr/lib64
USR_LOC_LIB=/usr/local/lib64

INSTALL_ROOT=$START_DIR
PI_ROOT=`cd ..; pwd`
PLEORA_ROOT=`cd $START_DIR/../../pleora; pwd`

REMOVE_LINKS=yes
INSTALL_DIR_OVERWRITE=yes

# Initial screen
clear
echo -n "Remove Picam SDK installed in directory '$INSTALL_ROOT' (yes/no) ? "
read ANSWER
if [ ! "$ANSWER" = "yes" ]; then
  echo "Uninstall cancelled."
  exit;
fi

if [ ! -w $INSTALL_ROOT ]; then
  echo "You do not have write permissions to '$INSTALL_ROOT'."
  echo "Run installer as super user (root)."
  exit 1
fi

echo "Removing software on $INSTALL_ROOT"
if [ -d $PI_ROOT ]; then
    rm -rf $PI_ROOT 
fi

#pleora removal
if [ -d $PLEORA_ROOT ]; then
    rm -rf $PLEORA_ROOT 
fi

if [ "$REMOVE_LINKS" = "yes" ]; then
  rm -rf $USR_LOC_LIB/libPv*
  rm -rf $USR_LOC_LIB/libEb*
  rm -rf $USR_LOC_LIB/libPt*
  rm -rf $USR_LOC_LIB/libEbuser*
  rm -rf $USR_LOC_LIB/liblog*
  rm -rf $USR_LOC_LIB/libapr*
  rm -rf $USR_LOC_LIB/libG*
  rm -rf $USR_LOC_LIB/liblog*
  rm -rf $USR_LOC_LIB/libM*
# Picam references
  rm -rf /var/run/pits
  rm -rf $USR_LOC_LIB/libpi*
  rm -rf $USR_LOC_LIB/*.dat
  rm -rf /etc/ld.so.conf.d/picam.conf
fi


echo "Removal complete."
echo ""
echo ""

Skript se zachová třemi různými způsoby, dle toho odkud je zavolán. Před příkazy rm -rf dáme echo, abychom zjistili co se stane, ale bez následků.

Smaže co má:

# /opt/PrincetonInstruments/picam/
# ./uninstall.sh
Remove Picam SDK installed in directory '/opt/PrincetonInstruments/picam' (yes/no) ? yes
Removing software on /opt/PrincetonInstruments/picam
rm -rf /opt/PrincetonInstruments
rm -rf /opt/pleora

Zachrání nás inteligentní chování příkazu rm, jinak by nám smazal celý /:

rm: it is dangerous to operate recursively on `/'
rm: use --no-preserve-root to override this failsafe

# cd /root
# /opt/PrincetonInstruments/picam/uninstall.sh
Remove Picam SDK installed in directory '/opt/PrincetonInstruments/picam' (yes/no) ? yes
Removing software on /opt/PrincetonInstruments/picam
rm -rf /
rm -rf /opt/pleora

Smaže nám celý /home:

# cd /home/user
# /opt/PrincetonInstruments/picam/uninstall.sh
Remove Picam SDK installed in directory '/opt/PrincetonInstruments/picam' (yes/no) ? yes
Removing software on /opt/PrincetonInstruments/picam
rm -rf /home
rm -rf /opt/pleora

Chyba je na následujících řádcích:

START_DIR=`cd $START_DIR; pwd`
PI_ROOT=`cd ..; pwd`

Autor si neuvědomil, že spouští příkaz cd v subshellu, takže pracovní adresář v nadřízeném shellu zůstane stejný.

Pokud by se skript alespoň před spuštěním rm -rf zeptal, zda-li má smazat adresář XY, byla by větší šance, že si toho uživatel všimne.

V případě, že by se skript správně otestoval, tak by tato chyba neprobublala až k zákazníkovi.

Takže ponaučení na závěr. Nevěřte nikomu. Není od věci mrknou co je obsahem skriptu uninstall.sh, obzvláště pokud není příliš dlouhý. A do třetice. Zálohovat, zálohovat, zálohovat.

UPDATE: David ještě správně poukázal na řádek:

START_DIR=`dirname $0`

Skript by v případě zavolání, pomocí symbolického linku z jiného adresáře, také selhal.

Šlo by to vylepšit voláním:

START_DIR=$(readlink -f ${BASH_SOURCE[0]})

       

Komentáře

[gtz]

měl jste to autorovi reportovat ... ale jinak máte pravdu zálohovat, zálohovat.

[Fuky]

Samozřejmě jsem to tvůrcům reportoval, ovšem nedělám si iluze o rychlé nápravě, jejich reakční doba je několik měsíců, Linuxová verze pro ně evidentně není prioritou a malý zákazník pro ně nic neznamená. Je to velká škoda, protože by stačilo velice málo, aby jejich zákazníci byli nadmíru spokojeni.

[trekker.dk]

Ponaučení na závěr: skripty install.sh a uninstall.sh nikdy nespouštět a už vůbec ne pod rootem.

[R]

Pripomina mi to uninstall nejakej hry pre Windows. Default cesta pri instalacii bola "C:\Program Files\Sierra\blabla". Zmenil som to na "C:\games\blabla". Ked som to potom chcel odinstalovat, trvalo to nejako podozrivo dlho. Tak som pozrel do C:\games, ze co to robi - a polovica hier uz bola v prdeli...

[pavel]

Mohl by někdo napsat, jak se zjišťuje aktuální umístění souboru (absolutní cesta)? Co jsem se díval na internet, není to až tak triviální záležitost. Zajímalo by mě nejpoužívanější řešení v bashi - aby byla cesta správně v případě použití adresáře, symbolického odkazu, souboru a při použití .source ve skriptu.

[Jendа]

readlink -f by mohl pomoct

[Fuky]

Pokud jsem něco neopomněl, tak by to mělo jít např. takto:

readlink -f ${BASH_SOURCE[0]}

[Šangala]

Mimo readlink by tě mohlo zajímat:

includepath="$( cd -P "$( dirname "$0" )" && pwd )"

[z]

Autor si neuvědomil, že spouští příkaz cd v subshellu, takže pracovní adresář v nadřízeném shellu zůstane stejný.

Tak v tom problém teda opravdu není.

[Fuky]

Autorovi nikdo z nás do hlavy samozřejmě nevidí, ale nevidíme tam ani Tobě, takže klidně svou myšlenku rozveď.

[David Watzke]

Problém je očividně hned v

START_DIR=`dirname $0`

Tohle prostě v $0 dostane cestu toho, jak byl program zavolanej...

[Šangala]

To je pěkná ptákovina, co už jsem několikrát udělal taky .

[Fuky]

Jasně, určitě to není dobré takto řešit a je třeba na to upozorňovat, ostatní chyby mě tak naštvaly, že jsem si toho ani nevšiml, i když to řešíme v diskuzi. Každopádně pokud se špatně nastaví $START_DIR, tak to alespoň vypíše hlášku, kde uživatel zjistí, že se ho to ptá na smazání špatného adresáře, v případě, že se nezavolá skript přímo svým názvem, ale třeba pomocí linku, nebo se přesune na jiné místo.