futtatandó fájl

Linux-kezdő

Üdv!
Kezdő vagyok linux-ban.
Futtatható fájlt szeretnék létrehozni!

fut.sh fájlomba ezt írtam:

#!/bin/sh
echo "szia"

Adtam neki futtatási jogot!
Ezt írja ki:a parancs nem található

  • 2492 megtekintés

( vilmos.nagy | 2018. 05. 15., k – 14:54 )

ha az adott könyvtárban vagy: 


./fut.sh

vagy teljes elérési úttal indítsd.

( muszike | 2018. 05. 15., k – 14:59 )

Létezik a /bin/sh?

ls /bin/sh mit ír ki?

A lányom pár héten belül befejezi a hetediket. A tanagyagban arról még nem esett szó, hogy mi az a fájl, és mi teszi valamilyen fájllá - nem meglepő módon akadt, aki a tavalyi pascalos hetek alatt úgy gondolta, hogy a .pas .exévé átnevezésével születik az indítható program.

Szóval újsor meg kocsivissza nem lesz az alapok között. Mivel a file explorer és a hexa nézet nem összeegyeztethető fogalmak, még a véletlen sem fogja felkelteni a kíváncsiságot úgy, mint hajdan a norton commander próbálgatásának idején.

Kövezz meg, de azzal szerintem semmi gond nincs, hogy nem az alapműveltség része ez az egész. Igazából, klasszikusokat idézve azoknak a tarack-kurvaanyját a ravatalon a seggbe akik ezt a csodát előadták úgy fősodratú mérnökileg. Nem normális, hogy az effektív hogyan kell ezt ábrázolni, mikor konkrétan átmegy a kábelen bitvadász eseten kívül ilyenekkel foglalkozni kelljen. Illetve ezzel a konkrét esettel egy normális világban speciel még ott sem kellene. Nagy tragédiája az ITnak, hogy az a nép futtatta fel, akiknek a legrövidebb az ABCje mind közül.

Elméletileg a közlekedés csak arról szól, hogy haladjunk és ne ütközzünk össze - ennyi az egész. Gyakorlatilag meg Ukrajnában csak tavaly óta van a körfogalomban benn lévőnek elsőbbsége, a birminghami nyugdíjas szénbányász meg a mai napig a jobb oldalon tekeri a kormányt az út bal oldalán.
Vízcsőtől nem várjuk el, hogy metrikus legyen a menete, mert nem az lett.
Az egyáltalán nem hülye, és a valósághoz jellemzően ragaszkodó villanyászok meg az áramforrás pozitív sarka felől indítják az áramot.
Mindez holt tudás, felesleges - amíg az ember oda nem kerül.

"Gyakorlatilag meg Ukrajnában csak tavaly óta van a körfogalomban benn lévőnek elsőbbsége"

Itthon meg még ma sincs, erre varrj gombot. :)

Tisztában vagyok vele, hogyan befolyásolja egy római ló segge a holdraszállást, ettől még nem kell szeretnem ezeket a maradékokat. Egy jó részüknek egyébként nyilván akkor és ott volt oka, egy másik jó részüknek meg akkor jó ötletnek tűnt, nem gondoltuk, hogy ez majd így velünk marad, aztán lehet vele szopni.

Ráadásul nem azt mondom, hogy ez felesleges tudás, hanem azt mondom, hogy ennek ilyen szinten nem kellene kilógni a userlanding, hogy egy felhasználónak tisztában kelljen vele lenni, hogy a rohadt sorvégét több féle képpen lehet ábrázolni. ( Ráadásul ez még független is a másik ilyentől, a karakterkódolástól. ) Vagyis nem gond, hogy nem az alapműveltség része ez. Gondoltam az idézet cizelláltságából lejön, hogy direkt sarkosított vélemény.

( kisbetu v | 2018. 05. 15., k – 15:56 )

"Kezdő vagyok linux-ban."

Ennyi ideje regisztrált felhasználó
2 év 50 hét

Nem kezdő az, csak minden topikot elkezdő és félbehagyó.

mi a kezdő, és mi a Linux...

pl. használok valamilyen Linuxot, böngészésre, filmnézésre, stb... de másba nem megyek bele, csak felhasználói programok használatába... regisztrálok a hup.hu-n is hátha előjön valami probléma, amiről kérdeznem kell. Aztán 2 év 50 hét után kipattan a fejemből, hogy shell scriptet akarok írni.

ez a példa Linuxnak Linux... de kezdő vagy sem?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( sigellef | 2018. 05. 16., sze – 09:40 )

Kezdő koromban én is megfutottam ezt a kört :)

1. a script első sora (ha bash script... ha másféle akkor értelemszerűen a másféle futtató):
#!/bin/bash

2. futtatási jogot neki:
chmod 755 fut.sh

3. futtatjuk:
./fut.sh

4. ha zavar a ./
sudo cp fut.sh /usr/bin

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Egy kezdő az ötletbörze helyett akár tanulhatna néhány alapismeretet.

1. Sok esetben a : is elegendő (de nem követendő) az első sorban.

2. A futtatási jogként sokkal hasznosabb a 700 vagy 500. A 755 máris pongyolaságra nevel.
Pótlecke: umask.

3. A fenti okosságok helyett alkalmazható az alábbi:
. ./fut.sh
Már, ha tudod mit csinálsz.

4. A /usr/bin az operációs rendszer része. Kezdőként különösen nem piszkáljuk!
Ha egy sor scriptet sem tudsz megírni, akkor elég nagy tévedés a sudo.
Egyébként a sudo a trehány emberek végső menedéke. Azért vannak a pontosan megtervezett jogosultságok, (pszeudo) felhasználók és csoportok, hogy bármilyen helyzetet meg lehessen oldani.
Persze ehhez megint csak tanulgatni kellene!
Amit ennek ellenére sem lehet kivitelezni, arra ott az acl. De kétlem, hogy egy kezdő - a fenti ismeretek hiányában - hatékonyan tudná használni. Vagy tipikusan speciális jogosultság konstellációt tudna előállítani.

#1. A 755 miért pongyolaság? Általában paranoid vagyok, és pl. zavar, ha valaki indokolatlanul $i -t ír "$i" helyett shell-ben. (Vagyis nekem pl. a " elhagyása a pongyolaság.)

De azt hogy a group + other olvashassa a scriptemet, nem érzem annak. On the contrary: A security by obscurity elvtől kifejezetten feláll a szőr a hátamon.

#2. én sem szeretem a sudo-t, de hívhatod sudo-nak, pfexec-nek, vagy bárminek attól függően, hogy melyik lábbal keltél, meg milyen fajta rendszzered van. De mi van amikor bizonyos jogosultságokat operátoroknak ki kell adni/ delegálni?
Na most, ha a végrehajtandó történet meg shell/python/etwas script formájában manifesztálódik, akkor _Linuxon_ sajnos nem nagyon van más menedék, mint a sudo. Cserébe egy relative korrektül, jól körbeírható szabályrendszer, hogy ki, milyen user nevében és mit hajthasson végre.
Tudom, hogy nem a linux az egyetlen rendszer, és csak a linux ilyen gyenge security designban, hogy még rendesen egy setuid bit sem mindig lekezelhető... De sajnos ez lett a mainstream. Mostanra már a sudo, de facto standard eszköz szinte minden unixon.

De kiváncsi vagyok, hogy a sudo nélkül hogyan oldanál meg ilyen problémát, ahol adott usernek kell delegálni végrehajtási jogot, hogy másik adott user nevében futtathasson le valamit.
Az, hogy ssh kulccsal bemegy és csinál dolgokat... Noss, nem annyira könnyen adminisztrálható, és nehezebb is a kontrol, stb.

Szóval, pls. oszd meg kérlek, hogy te hogyan kezelnéd ezeket a problémákat, ha szerinted ezek az eszközök szerinted ennyire nem jók!

Egy kezdőnek követendő rutinként tanítani a 755 használatát, na az a pongyolaság. Ha a home jogosultsága 700, akkor még értelme sincs.

csak a linux ilyen gyenge security designban, hogy még rendesen egy setuid bit sem mindig lekezelhető
Alapvető tévedés. A scripten nem működő setuid az pont a biztonságosabb rendszerek tulajdonsága.

ahol adott usernek kell delegálni végrehajtási jogot
Meg a naplózás, hogy ki mit csinált. :-)
Igen, láttam már ilyet. A cég megcsinálttatta, hogy jóskapista júzerként lehessen bejelentkezni (mert azt látod), méghozzá egy olyan környezetben, ahol nagyságrendekkel fejlettebb biztonsági megoldásokat lehetett volna igénybevenni. Pedig a rendszer addig is naplózta, hogy honnan (==ki) jelentkeztek be. Sajnos az egész olyan környezetre készült, amiben ezt nem lehetett megcsinálni. Leszögezném nem én vagyok a naaagy hekker, de 30s elegendő volt arra, hogy követhetetlenül bejussak a rendszerbe. Ennek nem az a tanulsága, hogy ki az okos vagy sem, hanem rossz volt a megoldás.

Azért kicsit tájékozódtam: a sudo "1980 körül" keletkezett. Igaz, én sem linuxon dolgoztam régebben. Szerencsére ezeket a dolgokat tervezéssel és acl segítségével már akkor megtanultam megoldani, amikor a linuxon csak 15 évvel később jelent meg az acl igen gyenge kezdeménye. ;)
Már-már nevetségesen sokszor kerültem olyan helyzetbe, amikor "pontleszarom mi fut le a pécéden néhány adattal!". Nekem az összes adattal, éles környezetben kell üzemeltetnem 7x24-ben a programot.
Tehát a megoldás:
1. A programfejlesztő elkészíti a programot.
2. A cél rendszer biztonsági környezetéhez illeszti. (Persze könnyen elképzelhető, hogy ezt már az 1. pont megvalósításkor el kell kezdeni.)
3. Az üzemeltető üzembe helyezi az alkalmazást - a dokumentáció szerint.

Természetesen lehet ennél egyszerűbben, de ezek javarészt ad hoc megoldásnak tekinthetők.

Egy egyszerű példa.
A jogosultságok az erőforrások (pl. interfész, futtatási jog) kezeléséről szólnak. Ősi megoldás a uucp group, amely használhatja a /dev/modem erőforrást. A cél, hogy jóskapista júzer modemezhessen. Lehetne a root jogosultsággal használni a modemet sudo segítségével, még sem teszik. Egyszerűen a /dev/modem kap megfelelő jogosultságot, ami még nem elégséges. Ezért jóskapista group member lesz a uucp group-ban, amely lehetővé teszi az /usr/bin/kermit setgid bitjének felhasználásával a /dev/modem elérését. Ugyanakkor jóskapista nem piszkálhat hozzá.
Ebből a példából látszik a tervezés, pedig se sudo, se acl.
A szkriptekre ez nem igaz, de sebaj! Megfelelő futató környezet kialakításával majdnem mindent meg lehet oldani.

Annak meg nem látom a lehengerlő előnyét, ha pl. a mount parancsot jogosultság híján nem tudod futtatni, DE a sudo mount esetén ugyanez naplózásra kerül.

Végezetül számtalan olyan alrendszer létezik, amellyel kialakítható a security akár kész template-ek felhasználásával. Persze ez is tervezést, előre gondolkodást igényel, no meg munkaigényes. Éljen a sudo!

Alapvető tévedés. A scripten nem működő setuid az pont a biztonságosabb rendszerek tulajdonsága.

Ezt mondjuk érvekkel is alá tudnád támasztani? Ne haragudj, de ez így, ebben a környezetben csak ex cathedra ideböfögés!

Igen, láttam már ilyet. A cég megcsinálttatta, hogy jóskapista júzerként lehessen bejelentkezni (mert azt látod), méghozzá egy olyan környezetben, ahol nagyságrendekkel fejlettebb biztonsági megoldásokat lehetett volna igénybevenni. Pedig a rendszer addig is naplózta, hogy honnan (==ki) jelentkeztek be. Sajnos az egész olyan környezetre készült, amiben ezt nem lehetett megcsinálni. Leszögezném nem én vagyok a naaagy hekker, de 30s elegendő volt arra, hogy követhetetlenül bejussak a rendszerbe. Ennek nem az a tanulsága, hogy ki az okos vagy sem, hanem rossz volt a megoldás.

Mi értelme ideböffenteni egy sztorit konkrétumok nélkül és csak az érzéseidet leírva róluk? Ne haragudj, de ezek sem nem érvek, sem arról nem ad semmi infót, hogy igaziból mi történt. Egy dolgot tettél nyilvánvalóvá: Valahol történt valami blődség, amiről neked legalábbis az a véleményed, hogy blődség volt. Nem mondom, hogy nem az volt.

De ugye érted mi a problémám a stílusoddal?

Mesélj, hogy oldod meg acl segítségével, hogy u1 user lefuttathassa s1 scriptet, hogy a közben létrejövő processznek u0 user jogosultságai legyenek a végrehajtódáskor?
És ezt tetszőleges mátrixban!


Egy egyszerű példa.
A jogosultságok az erőforrások (pl. interfész, futtatási jog) kezeléséről szólnak. Ősi megoldás a uucp group, amely használhatja a /dev/modem erőforrást. A cél, hogy jóskapista júzer modemezhessen. Lehetne a root jogosultsággal használni a modemet sudo segítségével, még sem teszik. Egyszerűen a /dev/modem kap megfelelő jogosultságot, ami még nem elégséges. Ezért jóskapista group member lesz a uucp group-ban, amely lehetővé teszi az /usr/bin/kermit setgid bitjének felhasználásával a /dev/modem elérését. Ugyanakkor jóskapista nem piszkálhat hozzá.

Te egy tök másik témáról beszélsz!
Ez így persze, hogy megy.

De teszem azt, hogyan teszed lehetővé, hogy operator user le tudja futtatni a backupot, úgy hogy közben a backupolt datasethez nem fér hozzá? Vagy pl. hogy készíthessen egy snapshotot a datasetről?

Lehet, hogy még így is túl-egyszerűsítettem a példát. De nyilván, amikor olyan "blőd"-egyszerű dologról van szó, mint ami modem-es példát felhozol, az azt mutatja, hogy kb 20 éve vagy a szakmában, de kb. a szakmai tudásod annyit fejlődött ez alatt a 20 év alatt, mint aki kb. 6 hónapja van a szakmában: nem találkoztál még komplexebb problémával, ezért feltételezed, hogy mindent egy fél karmozdulattal lesöpörhetsz.

Nyugodj meg, nem vagy különleges! A Duning-Kruger hatás pont ennek a jelenségnek a leírásáról szól!

A szkriptekre ez nem igaz, de sebaj! Megfelelő futató környezet kialakításával majdnem mindent meg lehet oldani.

Nocsak?! Most már majdnem mindent?!

Annak meg nem látom a lehengerlő előnyét, ha pl. a mount parancsot jogosultság híján nem tudod futtatni, DE a sudo mount esetén ugyanez naplózásra kerül.
Duning-Kruger! Jól jegyezd meg padawan, amikor úgy tűnik, hogy mindenki hülye, csak te vagy helikopter...
Érdemes kicsit az én vagyok a faszagyerek komfortzónából kilépni és tanulni! ;-)
Ez az első lépés affelé, hogy valaki ne tűnjön egy arrogáns fasznak a hup-on! ;-)

Az AIX mindig is B2 besorolású rendszer volt. Ez elég komoly érv. ;)

Mi értelme ideböffenteni egy sztorit..
Mert ez is egy sudo-szerű megoldás volt. Meg naplózott is (amit említettél). És bocsánat, ha véleményt nyilvánítok meg érzelmeket. Tudod, szeretnék róla beszélni. ;)

De teszem azt, hogyan teszed lehetővé, hogy operator user le tudja futtatni a backupot...
Fingom sincs. Biztosan sudo-val. :-D
Bár olyat meg tudtam csinálni, hogy egy csak windows-os játékokhoz értő gyerek le tudja futtatni a linux alapú backupot. Bejelentkezés nélkül.
Komolyabban: Odaírtam, csak annyit dunningkrugerezel, hogy nem értetted meg. :(

Hasonló a modemes példa is. Írtam már olyan scriptet, amit x user használt arra, hogy y user adataiból titkosított backupot készítsen (ehhez ugye néhol kell az y jogosultság), majd z userként cd-re kiírja (az íróhoz szükséges jogosultság és a szoftverhez szükséges hard ulimit miatt). Eközben sem az y környezetet, sem az adatokat nem érte el. Ez annyiban hasonlít a modemes példához és a kérdésed megoldásához is, hogy
- script
- nincs setuid, setgid
- nincs sudo
Viszont user és group kombinációval - no jó, egy-két acl segítségével - megoldható. Ezért a szerinted elavult tudást inkább alapos tudásnak hívnám. :-)
Természetesen ezt is írtam már, miszerint környezet is szükséges hozzá.
Azért csak "majdnem" mindent, mert léteznek olyan programok, amelyek csak real uid alatt futnak. De ezt bizonyára tudtad, csak kötözködsz. Vagy nem tudtad és csak okoskodsz.

A 20 évet majdnem eltaláltad. Pár hónap híján ennyit fejlesztettem csak AIX-en. ;) Előtte még néhány unix-fajtaságon, utána és közben néhány linux-féleségen.
És teljesen ráhibáztál: nem találkoztam komplex problémával!
Bár azért néhány komplex rendszert már készítettem. :-D
Az ellentmondás feloldása nagyon egyszerű! Nem szeretem a komplex dolgokat, nem is tudom megoldani. De nagy szerencsémre eredetileg hardverfejlesztő voltam. Éppen ezért egy komplex problémát elemi műveletekre (mintegy részáramkörökre) bontok, majd kidolgozom a részleteket. Utána csak össze kell rakni néhány műveletet akcióvá, amit az automata vezérlési sémájába beillesztek. Ha összeállt a vezérlés, akkor már több ilyen rendszer akár kooperálhat is egymással. Sajnos csak ehhez értek, az operátorok meghajtásához nem. :(

Ha már ennyire dunningkrugerezel, lenne egy jótanács-set-em. ;) Próbáld meg elképzelni a következőket:
- Hátha nagyobb fejlesztői tapasztalatom van, mint neked.
- Hátha több és komplexebb rendszert készítettem, mint gondolnád.
- Ha valamiért bármilyen kijelentésem ex katedrának tűnne, akkor
-- esetleg pont Te nem tudsz valamit, ezért
-- próbálj meg utánanézni, mielőtt lehülyézel. (Tudod, ha valamit állítok, azt valószínűleg már csináltam. Működött is, ráadásul éles környezetben.)
-- Ha nem megy az utánanézés, akár meg is kérdezheted.
-- Senki nem indít linux tanfolyamot a fórumon. ;) Ha állítok valamit, akkor sem fogok akár több oldal man-t automatikusan linkelni.
- Ha kihasználom az operációs rendszer adta lehetőséget, az nem egyenlő a nemtudással.
- Sok mindenben lehet jó programot írni, nem csak python-ban. :)

Viszont a legfontosabb olyan, mint az Asimov féle robot-ember kérdés. A megrendelőt sok esetben csak az érdekli, hogy egy program minden szempontból megfelelően működik. Kár lenne a mindenféle (esetleg házi) fejlesztési szabványra meg a legmodernebb elvekre hivatkoznod! Ha jók a szabályok akár jó is lehet. Sokszor meg csúnyán visszaüt.