Kuidas kasutada partiifaili, et muuta PowerShelli skriptid lihtsamaks

Mitmel põhjusel, enamasti turvalisusega seotud, ei ole PowerShelli skriptid nii hõlpsasti kaasaskantavad ja kasutatavad kui partiiskriptid. Kuid nende probleemide ümber töötamiseks saame meie PowerShelli skriptidega partii skripti siduda. Siin näitame teile mõned neist probleemsetest valdkondadest ja kuidas ehitada partiiskripti nende ümber.

Miks ma ei saa lihtsalt oma .PS1-faili kopeerida teisele arvutile ja käivitada?

Kui sihtsüsteem ei ole eelnevalt konfigureeritud, et võimaldada suvaliste skriptide käivitamist, nõutavate privileegidega ja kasutades õigeid seadeid, siis tõenäoliselt hakkate seda tegema, kui proovite seda teha.

1. PowerShell ei ole vaikimisi seotud .PS1-faililaiendiga.
   Me tõime selle algselt meie PowerShell Geek Schooli seeriasse. Windows seostab .PS1-failid Notepadiga vaikimisi selle asemel, et saata need PowerShelli käsulehele. Selle eesmärk on vältida pahatahtlike skriptide juhuslikku täitmist, topeltklõpsates neid. On olemas viise, kuidas seda käitumist muuta saab, kuid see ei ole ilmselt midagi, mida soovite teha igas arvutis, kuhu teie skriptid on kaasas - eriti kui mõned neist arvutitest pole teie enda.
2. PowerShell ei võimalda vaikimisi skriptide välist teostamist.
   PowerShelli seadistus seadistuses ExecutionPolicy takistab väliste skriptide täitmist vaikimisi kõigis Windowsi versioonides. Mõnes Windowsi versioonis ei võimalda vaikimisi skripti täitmine üldse. Näitasime teile, kuidas seda seadet muuta, kuidas lubada PowerShelli skriptide täitmist operatsioonisüsteemis Windows 7. See on ka midagi, mida te ei soovi teha mis tahes arvutis.
3. Mõned PowerShelli skriptid ei tööta ilma administraatori õigustega.
   Isegi siis, kui töötate administraatori tasemel kontoga, peate teatud toimingute sooritamiseks ikka veel läbi kasutajakonto kontrolli (UAC). Me ei taha seda keelata, kuid see on ikka tore, kui saame sellega veidi lihtsamalt toime tulla.
4. Mõnedel kasutajatel võib olla kohandatud PowerShelli keskkond.
   Sa ilmselt ei satu seda sageli, aga kui te seda teete, võib see skripte käivitada ja tõrkeotsingut tekitada. Õnneks saame selle ümber käia, tegemata ka püsivaid muudatusi.

1. samm: käivitamiseks topeltklõpsake.

Alustame esimesest probleemist - .PS1 faililiidetest. Sa ei saa .PS1-failide käivitamiseks topeltklõpsata, kuid sellisel viisil saab .BAT-faili täita. Niisiis, me kirjutame partiifaili, et helistada PowerShelli skriptile käsurealt.

Seega ei pea me iga skripti jaoks partiifaili uuesti kirjutama, või iga kord, kui skript ümber liigub, kasutab see PowerShelli skripti failiraja ehitamiseks enesele viitavat muutujat. Selle töö tegemiseks tuleb partiifail paigutada samasse kausta nagu PowerShelli skript ja sama failinimi. Seega, kui teie PowerShelli skripti nimetatakse "MyScript.ps1", tahad nimetada oma partiifaili "MyScript.bat" ja veenduda, et see on samas kaustas. Seejärel pange need read partii skripti:

@ECHO OFF PowerShell.exe-käsk "& '% ~ dpn0.ps1'" PAUSE

Kui see ei oleks olnud teiste turvapiirangute jaoks, siis oleks see tõesti kõik, mida vajate PowerShelli skripti käivitamiseks pakettfailist. Tegelikult on esimene ja viimane rida peamiselt vaid eelistus - see on teine ​​rida, mis tegelikult tööd teeb. Siin on jaotus:

@ECHO OFF lülitab käsu kaja. See hoiab teie teised käsud ekraanil, kui partiifail töötab. Seda joont peidab endas sümboli at (@) kasutamine.

PowerShell.exe -Command “& '% ~ dpn0.ps1'” tegelikult töötab PowerShelli skript. PowerShell.exe võib muidugi kutsuda mis tahes CMD aknast või partiifailist, et käivitada PowerShell tavapärasele paljale konsoolile. Võite seda kasutada ka käskude käivitamiseks otse pakettfailist, lisades -Command parameetri ja sobivad argumendid. See, kuidas seda meie .PS1-faili sihtimiseks kasutatakse, on spetsiaalne% ~ dpn0 muutuja. Jookse partiifailist,% ~ dpn0 hindab partiifaili draivitäht, kausta tee ja faili nime (ilma laiendita). Kuna partiifail ja PowerShelli skript on samas kaustas ja neil on sama nimi, tõlgib% ~ dpn0.ps1 PowerShelli skripti täielikku faili rada..

PAUSE lihtsalt peatab partii täitmise ja ootab kasutaja sisendit. See on üldjuhul kasulik partiifailide lõpus, nii et teil on võimalus vaadata enne mis tahes akna kadumist läbi mis tahes käsu väljund. Kui me läbime iga sammu testimise, muutub selle kasulikkus ilmsemaks.

Niisiis, põhifaili fail on loodud. Demonstratsiooniks salvestatakse see fail „D: Skripti Lab MyScript.bat” ja samas kaustas on “MyScript.ps1”. Vaatame, mis juhtub, kui me topeltklõpsame MyScript.bat.

Loomulikult ei jooksnud PowerShelli skript, kuid see on oodata - me oleme alles käsitlenud ainult esimest neljast probleemist. Siin on siiski mõned olulised bitid:

1. Akna pealkiri näitab, et partii skript käivitas edukalt PowerShelli.
2. Väljundi esimene rida näitab, et kohandatud PowerShelli profiil on kasutusel. See on ülaltoodud potentsiaalne probleem # 4.
3. Veateade näitab kehtivaid piiranguid. See on meie probleem # 2.
4. Veateate allakriipsutatud osa (mis on sisuliselt tehtud PowerShelli veaväljundi abil) näitab, et partii skript oli suunatud sihtotstarbelisele PowerShelli skriptile (D: Skripti Lab MyScript.ps1). Nii et me vähemalt teame, et palju töötab korralikult.

Sel juhul on profiil lihtne lihtliin, mida kasutatakse selle demonstratsiooni jaoks, et genereerida väljundit, kui profiil on aktiivne. Seda saab teha ka oma PowerShelli profiili kohandamiseks, kui soovite neid skripte ise testida. Lihtsalt lisage oma profiiliskriptile järgmine rida:

Kirjutage väljund 'Kohandatud PowerShelli profiil'!

Siin asub testisüsteemi ExecutionPolicy režiim RemoteSigned. See võimaldab teostada lokaalselt loodud skripte (nagu profiili skript), blokeerides väljastpoolt pärinevaid skripte, kui neid ei ole allkirjastanud usaldusväärne asutus. Demonstreerimise eesmärgil kasutati MyScript.ps1-i välise allikast märgistamiseks järgmist käsku:

Add-Content -Path D: skripti Lab MyScript.ps1 '-Value "[ZoneTransfer]' nZoneId = 3" -Stream "Zone.Identifier"

See seab Zone.Identifieri alternatiivse andmevoo MyScript.ps1-s nii, et Windows arvab, et fail tuli Internetist. Seda saab kergesti ümber pöörata järgmise käsuga:

Clear-Content -Path D: skripti Lab MyScript.ps1 '-Stream' Zone.Identifier '

Samm 2: ExecutionPolicy liikumine.

ExecutionPolicy seadistuse, CMD või partii skripti, liikumine on tegelikult üsna lihtne. Muudame lihtsalt skripti teist rida, et lisada veel üks parameeter PowerShell.exe käsule.

PowerShell.exe -TäitminePolicy Bypass -Command "& '% ~ dpn0.ps1'"

Parameetrit -ExecutionPolicy saab kasutada uue PowerShelli seansi loomisel kasutatava rakenduse Poliitika muutmiseks. See ei toimu pärast seda seansi, nii et me saame PowerShelli niimoodi juhtida, kui vajame, ilma süsteemi üldist turvalisuse asendit nõrgendamata. Nüüd, kui oleme selle kindlaks määranud, laseme veel üks minna:

Nüüd, kui skript on nõuetekohaselt teostatud, näeme, mida see tegelikult teeb. See annab meile teada, et käime skripti piiratud kasutajana. Skripti haldab tegelikult konto, millel on administraatori õigused, kuid kasutajakonto juhtimine on teel. Kuigi üksikasjad selle kohta, kuidas skript on administraatori juurdepääsu kontrollimisel, ei kuulu käesoleva artikli reguleerimisalasse, on siin näidiseks kasutatav kood:

kui (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()) IsInRole ([Security.Principal.WindowsBuiltInRole] "Administraator")) Kirjutusväljund "Töötab administraatorina!" Write-Output 'Running Limited!

Samuti märkate, et skripti väljundis on nüüd kaks „Paus“ operatsiooni - üks PowerShelli skripti ja teine ​​partii failist. Selle põhjus on selgem järgmises etapis.

3. samm: administraatori juurdepääsu saamine.

Kui teie skript ei käivita ühtegi käsku, mis vajavad kõrgust, ja te olete päris kindel, et te ei pea muretsema kellegi kohandatud profiilide pärast, võite selle ülejäänud osa vahele jätta. Kui kasutate siiski mõningaid administraatoritaseme cmdlete, on teil vaja seda tükki.

Kahjuks ei ole võimalik UAC-i ülestõstmiseks batch-faili või CMD seansi jooksul käivitada. Kuid PowerShell võimaldab meil seda teha Start-protsessiga. Kui kasutate koos argumentidega „-Verb RunAs”, püüab Start-protsess käivitada administraatori õigustega rakenduse. Kui PowerShelli seanss pole veel tõusnud, käivitab see UAC-i. Et seda skripti käivitamiseks kasutada partiifailist, jõuame lõpuks kahe PowerShelli protsesside kudemiseni - üks käivitada Start-protsess ja teine, mida käivitab Start-Process, et skripti käivitada. Partiifaili teine ​​rida tuleb muuta:

PowerShell.exe-käsk "& Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -Fail" "% ~ dpn0.ps1" "' -Verb RunAs"

Partiifaili käivitamisel on esimene väljundrida, mida me näeme, PowerShelli profiili skriptist. Seejärel käivitub UAC-käsk, kui Start-Process üritab käivitada MyScript.ps1.

Pärast UAC-i käsu klõpsamist kudeb uus PowerShelli eksemplar. Kuna see on uus näide, näeme muidugi ka profiili skripti teadet. Seejärel käivitub MyScript.ps1 ja me näeme, et oleme tõepoolest kõrgendatud sessioonis.

Ja seal on ka põhjus, miks meil on kaks pausi ka siin. Kui mitte PowerShelli skripti puhul, siis me ei näe skripti väljundit kunagi - PowerShelli aken lihtsalt ilmub ja kaob kohe, kui skript on käivitatud. Ja ilma partiifaili pausita ei saaks me näha, kas PowerShelli käivitamisel esinesid vead..

4. samm: kohandatud PowerShelli profiilide liikumine.

Vabastame nüüd sellest vastikust profiilist, kas me oleme? Siin on see vaevalt isegi ebameeldiv, kuid kui kasutaja PowerShelli profiil muudab vaikesätteid, muutujaid või funktsioone viisil, mida te ei ole oma skriptiga ette näinud, võivad nad olla tõesti tülikad. See on palju lihtsam skripti käivitamine ilma profiilita, nii et sa ei pea selle pärast muretsema. Selleks peame veel kord muutma partiifaili teist rida:

PowerShell.exe -NoProfile -Command "& Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -Fail"% ~ dpn0.ps1 ""' -Verb RunAs "

Parameetri -NoProfile lisamine mõlemasse skripti käivitatud PowerShelli eksemplaris tähendab, et kasutajaprofiili skript on mõlemas etapis täiesti möödas ja meie PowerShelli skript töötab üsna prognoositavas vaikimisi keskkonnas. Siin näete, et kummagi kootud koorega ei ole ühtegi kohandatud profiili.

Kui te ei vaja oma PowerShelli skriptis administraatori õigusi ja olete 3. sammu vahele jätnud, saate seda teha ilma teise PowerShelli eksemplarita ja partiifaili teine ​​rida peaks välja nägema järgmiselt:

PowerShell.exe -NoProfile -TäitminePolicy Bypass -Command "& '% ~ dpn0.ps1'"

Seejärel näeb väljaanne välja selline:

(Muidugi, kui mitte-administraatori skriptid, siis võiksite seda teha ka siis, kui teie PowerShelli skriptis ei õnnestu lõpetada skripti lõppu, kuna kõik on salvestatud samasse konsooli aknasse ja seda hoiaks seal paus pärast seda. partii faili ikkagi.)

Täidetud partiifailid.

Sõltuvalt sellest, kas vajate oma PowerShelli skripti jaoks administraatori õigusi (ja te ei tohiks neid tegelikult taotleda, peaks lõplik partiifail nägema nagu üks allpool toodud kahest).

Ilma administraatori juurdepääsuta:

@ECHO OFF PowerShell.exe -NoProfile -TäitminePolitsei möödaviik - käsk "&"% ~ dpn0.ps1 "" PAUSE

Administraatori juurdepääsuga:

@ECHO OFF PowerShell.exe -NoProfile -Command "& Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -Fail"% ~ dpn0.ps1 ""' -Verb RunAs "PAUSE

Ärge unustage panna pakettfaili samasse kausta nagu PowerShelli skript, mida soovite seda kasutada, ja andke sellele sama nimi. Siis, olenemata sellest, millist süsteemi te need failid võtate, saate käivitada oma PowerShelli skripti, ilma et peaksite süsteemi mõnda turvaseadet ümbritsema. Sa võid kindlasti neid muudatusi käsitsi teha iga kord, kuid see säästab teid selle probleemi eest ja te ei pea muretsema muudatuste tagastamise pärast.

---

Viited:

• PowerShelli skriptide käivitamine partiifailist - Daniel Schroederi programmeerimis blogi
• Administraatori õiguste kontrollimine PowerShellis - Hei, skriptimängija! Blogi