Acest lucru nu are nimic de-a face cu scenariul tău. În shell Bash, ; este văzută ca o comandă de terminare pentru șirul de comenzi și apoi imediat după aceasta este o comandă secundară. Deci, de fapt, modul în care lucrurile dvs. au fost procesate după cum urmează.
Executați comanda înainte de ;:
./copycron.sh /home/apple /home/pie
Executați a doua comandă după ;:
reporniți
Pentru că ai executat probabil ca rădăcină sau superutilizator, a repornit cu succes.
Cu toate acestea, dacă faceți ceva mai specific și executați o altă comandă arbitrară după ; în schimb, veți observa că comanda este rulată. Cele două argumente ale scriptului dvs. vor rămâne /acasă/măr și /acasă/plăcintă respectiv. Scenariul nu vede niciodată ;reporniți parte pentru că nu este analizat ca argument. Aceasta este o limitare Bash și nu ceva din scriptul tău.
Puteți testa acest lucru cu următorul script și apoi apelurile de comandă:
FIȘIER: argecho.sh
#!/bin/bash
echo „Argumente delimitate de spațiu: $*”
ecou ""
ecou "------"
ecou ""
COMANDA DE EXECUTARE:
./argecho.sh foo bar baz /tmp/something.txt;echo Am făcut altceva
IEȘIRE:
$ ./argecho.sh foo bar baz /tmp/something.txt;echo Am mai făcut ceva în afara scenariului, vezi?
Argumente delimitate de spațiu: foo bar baz /tmp/something.txt
------
Am făcut altceva în afara scenariului, vezi?
Veți observa că „ecoul” și celelalte argumente din acesta nu au fost incluse în argumentele dumneavoastră în scriptul dumneavoastră. Acesta este comportamentul Bash standard.
Pe baza editărilor dvs., preocuparea dvs. este că cineva vă va deturna comenzile din depozitul Jenkins și va emite o comandă rău intenționată, schimbând scriptul din sh 'copycron "${Workspace}" "${targetdir}"' la sh copycron /home /boot;închidere
Din păcate pentru dvs., acest lucru nu are absolut nimic pe care să îl puteți remedia, acest lucru ar duce la eșecul dvs. de a controla corect cine are acces la depozitele de comenzi. Astfel de actori de amenințări ar avea mult mai mult acces pentru a vă deteriora sistemul, nu doar să ruleze o comandă simplă precum modificările menționate mai sus. Mai probabil că ar instala malware pe sistemul dvs., decât orice, și dacă nu vă securizați corect arhivele de comenzi, astfel încât nimeni să nu le poată „edita aleatoriu”, lipsa dvs. de control asupra depozitelor este ceea ce vă va pune peste cap.
Nu există nicio întărire reală pe care o putem face aici dacă utilizatorul jenkins are privilegii sudo nelimitate. Pur și simplu nu există, deoarece acest lucru se va baza pe asigurarea corectă a sistemelor sau construirea unui mecanism de implementare alternativ care este mai sigur și nu necesită sudo a lucra cu totul.
