Sziasztok!
Szerintetek ez miért nem működik?
Szeretném, ha egy bash script más felhasználó jogaival futna ha bárki elidítja. Ehhez a következőt csinálom:
A kívánt felhasználó jogaival létrehozom a fájlt:
# vi teszt.sh:
#!/bin/bash
whoami
:x!
Majd beállítom a futtathatóságot és a setuidet:
# chmod +x teszt.sh
# chmod +s teszt.sh
Ezekután a fájl így néz ki:
-rwsr-sr-x 1 geri www 19 aug 17 10:19 teszt.sh*
Más felhasználói névvel bejelentkezve és a programot lefuttatva azonban az eredmény a következő:
# su - tamas
#./teszt.sh
tamas
... vagyis a scriptben található "whoami" parancs szerint a várt output eredménnyel ("geri") ellentétben a user továbbra is "tamas", nem pedig a setuid "geri"... És sajnos ha más parancsot hajtok végre abban a szkriptben, pl. rsync, stb, az is a "tamas" jogaival hajtodik vegre, nem pedig a "geri" jogaival.
Most vagy én használom rosszul ezt a látszólag egyértelmű dolgot, vagy ezt ilyen formában meg sem lehet oldani? :(
- 1222 megtekintés
Hozzászólások
shell szkripten nem lehet setuidot használni
- A hozzászóláshoz be kell jelentkezni
Alap. Ráadásul a sudo korában tökéletesen felesleges is.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
:) visudo után a
tamas ALL=(geri) NOPASSWD: /path/to/script
sort hozzáadva, már működik is tamas-ként a sudo -u geri /path/to/script
- A hozzászóláshoz be kell jelentkezni
OK ezt nem tudtam... :)
Köszi!!! :)
- A hozzászóláshoz be kell jelentkezni
De lehet, csak nagyon nagyon erosen ellenjavalt.
Esetleg amiert nem szokott mukodni: nosuid-dal mount-olt filerendszer, kernelbeallitassal tiltva van.
- A hozzászóláshoz be kell jelentkezni
én úgy tudom hogy az általában az interpreteres szkriptekre nem lehet setuidot tenni, újabb unixoknál és linuxnál sem.
- A hozzászóláshoz be kell jelentkezni
Tenni éppenséggel lehet, csak figyelmen kívül hagyja a rendszer biztonsági okokból (race condition: az interpreter (például bash) indítása után, de még mielőtt maga a bash megnyitná a végrehajtandó fájlt, rosszindulatú támadó ki tudja cserélni az adott fájlt (például inket átirányít a rendszergazda setuidosáról egy másik fájlra)), ekkor a bash root jogokkal hajtana végre egy szkriptet, de nem azt, amelyiken a setuid bit van.
- A hozzászóláshoz be kell jelentkezni
Ok, köszi, ennyire pontosan én sem tudtam hogy mi az oka. Chmodolni persze hogy lehet, csak ugye ha nem setuidosként viselkedik akkor ugye nem 'tettél rá' setuidot, így értettem :)
- A hozzászóláshoz be kell jelentkezni
Jogos. :)
- A hozzászóláshoz be kell jelentkezni
de lehet, csak bash -p -vel kell inditani a bash-t (privileged)
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
suid perl is megoldas lehet helyette.
- A hozzászóláshoz be kell jelentkezni
No.. köszi mindenkinek. Végülis úgy oldottam meg, hogy a sudoers fájlt módosítottam (úgy, hogy ne kérjen jelszót, mivel ez egy remote automata szkript volna, amit több szerveren hív meg egyszerre egy második és harmadik szkript...), és a szkriptben pedig: "sudo rsync -a ...."
Így már működik :)
- A hozzászóláshoz be kell jelentkezni
Ja, amúgy érdekesség:
Úgy is próbáltam ügyetlenkedni, hogy csináltam egy másolatot az 'rsync' binárisból 'rsync_suid' néven. Aztán beraktam ugyanabba a könyvtárba, mint a szkript, és chmod +s ... . A szkriptben pedig átírtam, hogy az így SUID-é tett rsycet hívja meg.
Persze, nem működött. A SUID-es rsync a scriptből meghívva sem futott más felhasználó jogaival (míg szkripten kívül, shellből elindítva úgy működött, ahogy várni lehetett). Tehát, ezek szerint nem csak a szkriptet magát, de az abból meghívott programokat is hiába SUID-eled... Hm. :)
- A hozzászóláshoz be kell jelentkezni
szerintem azt kell irni az elejere, hogy
#! /bin/bash -p
lehet, hogy van mas megoldas is, ilyenkor a bash privileged mode-ban fut, es nem allitja vissza elvileg az effective user id-t a real user id-re.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni