Alle uitvoerpermissies verwijderd*

[X-Stuff]

Heb zojuist per ongeluk alle uitvoer permissions verwijderd van mijn bestanden op mijn server. Hierdoor dus ook CHMOD... Probleem is nu dus vrij logisch, kan niets meer doen, behalve een aantal basic commands.

Iemand enig idee hoe dit op te lossen?

- Zit nog wel in een SSH sessie, echter een nieuwe openen werkt ook niet meer.
- Heb wel toegang tot Webmin, echter is kale installatie. Geprobeerd file manager te installeren, maar die kan het .wbm file niet uitpakken aangezien TAR niet werkt.

Umask werkt ook maar kan geen nieuwe files aanmaken.

Is er een mogelijkheid om CHMOD op 755 te krijgen of een nieuwe CHMOD er op te zetten via een of andere manier. Bijvoorbeeld via Webmin.

Server is colocated en de toegang is schaars..Dus los het liever op een moeilijke manier op die me desnoods uren duurt dan dat ik langs moet gaan.

[Boudewijn]

uirtvoer permissions?

wat is dat?


welke distro\OS?
specs?

wat heb je al gedaan om het te fixen?

[ Voor 50% gewijzigd door Boudewijn op 20-12-2005 20:20 ]

[Emmeau]

enige wat ik zo kan bedenken op dit moment is als je ftp toegang hebt, daar een chmod mee te uppen en de permissies goed te zetten.

[fsfikke]

Boudewijn schreef op dinsdag 20 december 2005 @ 20:20:
uirtvoer permissions?

wat is dat?


welke distro\OS?
specs?

wat heb je al gedaan om het te fixen?

Misschien handig om niet te reageren als je geen id hebt waar de ts het over heeft
Hij heeft zich zelf alle rechten ontnomen op z'n ftp-server

[TrailBlazer]

heb je een chmod -R 600 / gedaan als dat hetgeval is kan je beter een reinstall doen. Je krijgt nooit je systeem volledig secuur als je dit gedaan hebt.
Overigens je kan het redelijk simpel rechten goed zetten met een knoppix cdtje denk ik zo

[ Voor 26% gewijzigd door TrailBlazer op 20-12-2005 20:25 ]

[X-Stuff]

Het was een CHMOD 644 of 664..

Een herinstallatie is ook de beste optie, alleen voor de tijd dat ik er niet fysiek bij kan zou ik graag een alternatief hebben zodat mail e.d. weer draait.

Als ik er naar toe FTP krijg ik te zien:

500 OOPS: cannot change directory:/home/xstuff
500 OOPS: child died
Server closed connection

Dit geldt voor alle FTP accounts, echter dan met hun eigen home dir.

[ Voor 176% gewijzigd door X-Stuff op 20-12-2005 20:37 ]

[webfreakz.nl]

Is www.pinac.nl ook het resultaat hiervan? Opzich als je het leest is het wel grappig dit! Alleen als beheerder van een remote server is dit moeilijk versleten!

* webfreakz.nl leeft met je mee

Ik denk zelf in de tijd dat je dit opgelost hebt, je zelf beter naar het desbetreffende datacenter kan gaan? Heb je geen SLA met je colocater dat die iets voor je kunnen regelen?

edit:

Heb niet zoveel te maken gehad met *NIX systemen, maar kan je niet overal alvast een chmod-777 overheen gooien? dan kan je al het nodige alvast backuppen?

[ Voor 19% gewijzigd door webfreakz.nl op 20-12-2005 20:52 ]

[DJ Buzzz]

webfreakz.nl schreef op dinsdag 20 december 2005 @ 20:48:
Heb niet zoveel te maken gehad met *NIX systemen, maar kan je niet overal alvast een chmod-777 overheen gooien? dan kan je al het nodige alvast backuppen?

Tsja, da's nogal lastig al je chmod binary geen execute rechten heeft...

[X-Stuff]

webfreakz.nl schreef op dinsdag 20 december 2005 @ 20:48:
Ik denk zelf in de tijd dat je dit opgelost hebt, je zelf beter naar het desbetreffende datacenter kan gaan? Heb je geen SLA met je colocater dat die iets voor je kunnen regelen?

Deze server draait colocated bij een kennis, als vriendendienst, die een "private" datacenter(tje) heeft. Hij is daar dus maar af en toe. En hij moet net tijd hebben. Deze server draait normaal gesproken als backup, daarvoor is het een mooie lokatie. Echter op dit moment ligt mijn main server er uit ivm verhuizing. En moest ik dus over naar me backup

[Sir Isaac]

sleutelen aan je backup server terwijl die je hoofd server vervangt..

[DataGhost]

Sir Isaac schreef op dinsdag 20 december 2005 @ 21:29:
sleutelen aan je backup server terwijl die je hoofd server vervangt..

daar heeft de TS vast heel veel aan, de beste stuurlui staan aan wal zeggen we maar
nontheless totaal stupide, zo'n actie

TS, waarschijnlijk wordt het een retourtje datacenter met een livecdtje en/of reinstall... Hiervoor werd dit ook al aangeraden maar vanuit een totaal verkeerd referentiekader (hoeveel mensen zonder kennis van zaken proberen hier nuttige replies te maken... security-compromised..puh). Het probleem is namelijk dat er gruwelijk veel bestanden op je systeem staan die lang niet allemaal dezelfde permissies (mogen/zouden moeten) hebben dat het mij een ondoenlijke klus lijkt deze allemaal te herstellen.
Wat ik zou doen is een backup maken van de belangrijke data en de bak opnieuw installen, wat je ook zou kunnen proberen is met chmod de permissies van je basisexecutables (wel vanuit de livecd) terug te zetten zodat je met je package manager AL je packages opnieuw kan installeren. Met gentoo kan dit heel makkelijk met iets gelijk aan 'emerge -e world'. Dan worden de permissies automatisch teruggezet en kan je mogelijk zonder reinstall en met minimale downtime verder werken op je server.

Wat je ook nog zou kunnen proberen (als hiervoor al aangedragen) is een chmod-binary te uploaden en hopen dat deze de goede permissies heeft/krijgt. Kleine kans dat het gaat werken maar nooit geschoten is altijd mis.

[Verwijderd]

Als je nog in de SSH sessie zit, kan je niet met een SCP achtige applicatie binnen dezelfde sessie chmod overseinen?

[X-Stuff]

Verwijderd schreef op dinsdag 20 december 2005 @ 21:41:
Als je nog in de SSH sessie zit, kan je niet met een SCP achtige applicatie binnen dezelfde sessie chmod overseinen?

Zit nog wel in de SSH sessie, heb alleen nog geen nuttige commando's gevonden die wat voor me kunnen betekenen.

[DJ Buzzz]

Wat heb je gevonden dat wel werkt dan? Ook geen open ftp sessie o.i.d.? In je openingspost noem je een aantal basis commando's die nog werken, welke zijn dat?

[dawuss]

chmod -R a+x / zet in ieder geval recursief op alle directories en files het execute bit weer aan. Niet echt een oplossing waar je vrolijk van wordt, maar als tijdelijke oplossing zou 't wel kunnen voldoen.

[X-Stuff]

djbuzzz schreef op dinsdag 20 december 2005 @ 21:59:
Wat heb je gevonden dat wel werkt dan? Ook geen open ftp sessie o.i.d.? In je openingspost noem je een aantal basis commando's die nog werken, welke zijn dat?

Dit soort commando's.. Geen ftp sessie helaas. Die trapt me eruit omdat hij de map niet in kan. En root heeft geen FTP access.

! caller done fc jobs pwd then until
./ case echo fg kill read time wait
: cd elif fi l readonly times while
[ command else for let return trap {
[[ compgen enable function ll select true }
]] complete esac getopts local set type
alias continue eval hash logout shift typeset
bg declare exec help ls shopt ulimit
bind dirs exit history popd source umask
break disown export if printf suspend unalias
builtin do false in pushd test unset

[Verwijderd]

dawuss schreef op dinsdag 20 december 2005 @ 22:00:
chmod -R a+x / zet in ieder geval recursief op alle directories en files het execute bit weer aan. Niet echt een oplossing waar je vrolijk van wordt, maar als tijdelijke oplossing zou 't wel kunnen voldoen.

chmod is ook de execute bit kwijtgeraakt en kan daarom niet uitgevoerd worden

http://www.ssh.com/suppor...p/32/file_transfer-3.html

Zoiets misschien? Kan je nog een nieuwe SSH sessie aanmaken? Weet anders niet of je dit progje ook binnen je bestaande sessie kan laten lopen.

[ Voor 23% gewijzigd door Verwijderd op 20-12-2005 22:14 ]

[dawuss]

Verwijderd schreef op dinsdag 20 december 2005 @ 22:13:
[...]


chmod is ook de execute bit kwijtgeraakt en kan daarom niet uitgevoerd worden

http://www.ssh.com/suppor...p/32/file_transfer-3.html

Zoiets misschien? Kan je nog een nieuwe SSH sessie aanmaken? Weet anders niet of je dit progje ook binnen je bestaande sessie kan laten lopen.

Dan upload je toch een nieuwe (statisch gelinkte) die wel de juiste modes heeft?

[X-Stuff]

dawuss schreef op dinsdag 20 december 2005 @ 22:17:
[...]

Dan upload je toch een nieuwe (statisch gelinkte) die wel de juiste modes heeft?

Hoe?

Geen FTP meer en een nieuwe sessie SSH sessie aanmaken gaat niet. Tenzij er in Putty een file transfer optie zit tijdens je huidige SSH sessie

[ Voor 13% gewijzigd door X-Stuff op 20-12-2005 22:22 ]

[Verwijderd]

X-Stuff schreef op dinsdag 20 december 2005 @ 22:21:
[...]


Hoe?

Geen FTP meer en een nieuwe sessie SSH sessie aanmaken gaat niet. Tenzij er in Putty een file transfer optie zit tijdens je huidige SSH sessie

Die kon ik iig niet vinden. Je hebt natuurlijk wel SCP maar geen idee hoe je die aan je huidige sessie attached?!

[kenneth]

Diep van binnen weet iedereen het antwoord wel ...

[tomato]

Welke shell gebruik je? Je zult het moeten doen met de build-in functies in je shell. Als je er daarmee niet uit komt geef ik je weinig kans.

[dawuss]

Hmm, je opties zijn in ieder geval erg dun. Ik kan in ieder geval niets meer bedenken wat nog gaat werken, anders dan op bit-niveau in je filesystem gaan lopen klooien, waar je waarschijnlijk dan ook weer geen executables voor hebt nu

In ieder geval ga je deze fout niet nog een keer maken geloof ik

[X-Stuff]

dawuss schreef op dinsdag 20 december 2005 @ 22:50:
Hmm, je opties zijn in ieder geval erg dun. Ik kan in ieder geval niets meer bedenken wat nog gaat werken, anders dan op bit-niveau in je filesystem gaan lopen klooien, waar je waarschijnlijk dan ook weer geen executables voor hebt nu

In ieder geval ga je deze fout niet nog een keer maken geloof ik

Denk het ook niet...

We gaan wel proberen het datecentrum in te komen. Bedankt voor je hulp

En de rest ook natuurlijk bedankt.

[tomato]

Hmm ik had een idee, maar helaas. Ik dacht eraan om 'umask u+rwx' uit te voeren (volgens mij is umask een shell built-in commando) zodat je vervolgens een nieuwe executable file aan kon maken (files aanmaken kun je op tig manieren). Daarna pomp je de inhoud van de chmod executable over naar die nieuwe file en kun je verder.

Het werkt niet omdat je wel +x kunt aangeven in je umask maar dat niet gebruikt wordt bij het aanmaken van files (+rw wel)... Toch moet een soortgelijk trucje wel mogelijk zijn. Ik zou de handleiding van m'n shell er toch even bijpakken, je weet nooit waar je nog op komt

[CyBeR]

Je hebt dus letterlijk alles ontdaan van execute-rechten? Niet op een gegeven moment je fout ingezien en op ^C gedrukt?

[Verwijderd]

Als je nog wel toegang hebt tot webmin dan werkt cgi perl dus blijkbaar nog wel, ik weet eigenlijk niet of de chmod functie van perl ingebouwd is of dat ie ook van de executable chmod gebruik maakt, maar misschien dat je perl cgi kan gebruiken om chmod weer terug te chmodden. Met alleen built in commando's kun je best een simpel scriptje maken.

Misschien dat php ook nog werkt, dan zou je hetzelfde truukje met php kunnen proberen, die kent ook een chmod functie.

Als dat allemaal faalt dan lijkt het me eigenlijk behoorlijk hopeloos.

[blaataaps]

Ik verander de topictitel even, de uitvoer van de permissions lijkt me niet verwijderd namelijk.

[tomato]

Verwijderd schreef op dinsdag 20 december 2005 @ 23:06:
Als je nog wel toegang hebt tot webmin dan werkt cgi perl dus blijkbaar nog wel, ik weet eigenlijk niet of de chmod functie van perl ingebouwd is of dat ie ook van de executable chmod gebruik maakt, maar misschien dat je perl cgi kan gebruiken om chmod weer terug te chmodden. Met alleen built in commando's kun je best een simpel scriptje maken.

Aardig idee. Je hebt waarschijnlijk het probleem dat je niet direct chmod mag uitvoeren op een nuttige executable (je webserver draait niet als root neem ik aan), maar bijvoorbeeld zsh heeft chown wel als built-in command geloof ik, daarmee zou je dan eerst de executable file dezelfde user kunnen geven als je webserver (ik neem aan dat je nog wel ingelogd bent als root, anders zou het sowieso een hopeloze zaak zijn en had je dit ook niet kunnen veroorzaken).

[Buffy]

Ik heb wel eens een verhaal gelezen waarbij ze mbv 'echo' een (minimale) binary over een bestand met uitvoerrechten hebben geschreven. Voorwaarde is wel dat je nog ergens een bestand met uitvoerrechten aan kan terug vinden (home directory?).

Als je 'chmod -R 644 /' hebt gedaan is dat ook geen optie

[ Voor 5% gewijzigd door Buffy op 21-12-2005 00:36 ]

[Verwijderd]

tomato schreef op dinsdag 20 december 2005 @ 23:24:
[...]

Aardig idee. Je hebt waarschijnlijk het probleem dat je niet direct chmod mag uitvoeren op een nuttige executable (je webserver draait niet als root neem ik aan)

De webserver heeft wel leesrechten op chmod lijkt me, dus eerst een kopie maken en daarna die kopie chmodden zou moeten lukken.

[X-Stuff]

tomato schreef op dinsdag 20 december 2005 @ 22:58:
Hmm ik had een idee, maar helaas. Ik dacht eraan om 'umask u+rwx' uit te voeren (volgens mij is umask een shell built-in commando) zodat je vervolgens een nieuwe executable file aan kon maken (files aanmaken kun je op tig manieren). Daarna pomp je de inhoud van de chmod executable over naar die nieuwe file en kun je verder.

Het werkt niet omdat je wel +x kunt aangeven in je umask maar dat niet gebruikt wordt bij het aanmaken van files (+rw wel)... Toch moet een soortgelijk trucje wel mogelijk zijn. Ik zou de handleiding van m'n shell er toch even bijpakken, je weet nooit waar je nog op komt

Dat had ik ook als idee, daarom dat ik in mijn start post vermelde dat umask nog werkte. Echter toen ik voor de test een "echo blaat > test" aanmaakte kon ik hem als nog niet runnen. Waarom wist ik niet, maar dat is me nu dus duidelijk. Wel vreemd dat hij dat negeerd. SSH client laat ik wel open staat, zolang me verbinding blijft draaien . Dus mocht je nog een oplossing vinden dan hoor ik het graag.

Zal zelf ook nog eens kijken nu je meer weer enige hoop gegeven hebt

Webmin is er trouwens al mee gestopt, helaas. Dus tot nu toe is alleen de SSH sessie over

[ Voor 10% gewijzigd door X-Stuff op 21-12-2005 00:33 ]

[DeMoN]

Over SCP, misschien heb je hier wat aan

Here is how scp works:(Note the use of periods; they are essential!!)

1) To copy a file from hostB to hostA, while logged in to hostB:

bash$ scp filename [e-mail]:.
(copies file to user's home dir on hostA machine, because of the period after the colon)

2) To copy a folder from hostB to hostA, while logged in to hostB first cd to the directory on HostB which contains the folder you want to copy:

bash$ scp -r folder [e-mail]:.(creates new folder if the folder does not exist, again in user's home directory)

3) To copy a file from hostA to hostB, while logged in to hostB:

bash$ scp [e-mail]:filename .
(copies into current directory on hostB)

bash$ scp -r [e-mail]:folder .
(copies whole folder into current directory on hostB)

4) To copy a file or folder within a folder from hostA to hostB, while logged in to hostB:

bash$ scp [e-mail]:/folder/dir/filename .
(copies into current directory on hostB)

bash$ scp -r [e-mail]:/folder/dir .
(copies whole folder into current directory on hostB)

5) Instead of using the '.' to designate files to be copied to a home directory or the current working directory you can give scp an actual path (assuming you have write permissions):

bash$ scp -r folder username@hostA:/home/httpd/

bash$ scp [e-mail]:/folder/dir/filename /home/tmp/

[X-Stuff]

scp doet het helaas ook niet, maar toch erg bedankt

Ben er wel wachter gekomen dat je met het Reiser4 file system de permissions kan wijzigen zonder chmod.

Bron: http://www.namesys.com/v4/pseudo.html

/mnt/1# # changing mode without chmod(2)
/mnt/1# echo 0777 > b/metas/rwx
/mnt/1# ls -l b
-rwxrwxrwx 1 100 0 0 Jun 16 13:32 b

Handig om te weten, alleen heb ik er nu niet veel aan

[ Voor 83% gewijzigd door X-Stuff op 21-12-2005 01:24 ]

[CyBeR]

DeMoN schreef op woensdag 21 december 2005 @ 01:08:
Over SCP, misschien heb je hier wat aan


[...]

Ten eerste mag die punt voor de remote homedir best weggelaten worden, ten tweede heeft TS er niets aan omdat er een 2e SSH proces gestart moet worden daarvoor, en dat ging niet

De enige optie die ik kan bedenken is een file opzoeken die nog wel execute rechten heeft en die overschrijven met de inhoud van chmod.

[ Voor 17% gewijzigd door CyBeR op 21-12-2005 01:22 ]

[Sendy]

Ik weet niet hoe het bovenstaande (DeMoNs copy-paste) iets zou kunnen helpen, maar scp lijkt wel een handige tool nu.

Als je nog kan scpen naar die machine kan je er een programma heen kopieren met scp -p. De p zorgt ervoor dat het programma zijn "modes" houdt (ch_mod_). Dus om het je makkelijk te maken (tenminste als ~/bin bestaat)

code:

scp -p /bin/chmod server:bin

edit:

Ja, jammer dat scp het niet meer doet.

[ Voor 14% gewijzigd door Sendy op 21-12-2005 01:28 ]

[X-Stuff]

Zou het mogelijk zijn om de inhoud van chmod te pasten naar een function?

Zoiets als:

function test { <inhoud chmod plakken> }

[CyBeR]

je kunt daar geen elf binary data neerplakken, nee.

[Verwijderd]

als ik het goed begrijp, is er wel ssh toegang. Verder is de webserver wel te bereiken, maar zijn er geen permissies.

Wat als je nu in de root van je webserver zelf een .php aanmaakt? Die kun je dan toch laten uitvoeren door je website aan te roepen hiermee?

dus bv.

echo "<?php echo 'helllo world';?>" > /var/www/helpmij.php

en dan

www.desite.nl/helpmij.php

Als dat nog wel werkt, is er iig. nog iets wat je kunt laten uitvoeren. Mogelijkerwijs dat je via die route verder kunt komen.

//edit
echo "<?php chmod('/usr/bin/chmod', 0777); ?>" > chmod.html

Als je niet je chmod kunt chmodden (), probeer dan in een web-writable directory een onzinnig bestand aan te maken en daar via het PHP script de permissies van te veranderen. Daarna cat je chmod naar dat bestand.

[ Voor 76% gewijzigd door Verwijderd op 21-12-2005 02:21 ]

[X-Stuff]

Zelfs dat werkt niet.. Waarom vat ik even niet, aangezien hij de files zou moeten aanmaken met read-write mode. Krijg gewoon een 403 Forbidden.

edit:
Ga maar is wat rusten, morgen maar eens kijken of we bij de server kunnen komen.

[ Voor 26% gewijzigd door X-Stuff op 21-12-2005 02:57 ]

[kenneth]

Nouja, je hebt in ieder geval een belangrijke les geleerd

[TrailBlazer]

DataGhost schreef op dinsdag 20 december 2005 @ 21:38:
[...]
TS, waarschijnlijk wordt het een retourtje datacenter met een livecdtje en/of reinstall... Hiervoor werd dit ook al aangeraden maar vanuit een totaal verkeerd referentiekader (hoeveel mensen zonder kennis van zaken proberen hier nuttige replies te maken... security-compromised..puh).

refereer je hier aan mijn post ifso wat klopt er dan niet aan. Jij beweert toch ook dat het een security probleem is

[dawuss]

X-Stuff schreef op woensdag 21 december 2005 @ 02:54:
Zelfs dat werkt niet.. Waarom vat ik even niet, aangezien hij de files zou moeten aanmaken met read-write mode. Krijg gewoon een 403 Forbidden.

Tsja... Je apache documentroot (/var/www of iets dergelijks) is ook niet executable voor het apache proces, en bij directories betekent dat... juist: dat je er niet in mag

[zomertje]

Ik ben ook bang dat het toch een retour colo gaat worden met een live cd. Of je moet via ssh een stukje in C kunnen schrijven dat een chmod kan uitvoeren. Maar dat mag weer niet in een programma gegoten worden want dat kan je weer niet uitvoeren Van C heb ik weinig kennis, maar ik heb wel eens leuke dingen gezien.

ps: laten we hier wel lief blijven voor elkaar he, iedereen doet zn best om te helpen (ga ik van uit)

[CyBeR]

zomertje schreef op woensdag 21 december 2005 @ 10:08:
Ik ben ook bang dat het toch een retour colo gaat worden met een live cd. Of je moet via ssh een stukje in C kunnen schrijven dat een chmod kan uitvoeren. Maar dat mag weer niet in een programma gegoten worden want dat kan je weer niet uitvoeren Van C heb ik weinig kennis, maar ik heb wel eens leuke dingen gezien.

ps: laten we hier wel lief blijven voor elkaar he, iedereen doet zn best om te helpen (ga ik van uit)

Daar had ik ook aan gedacht, maar om zo ver te komen moet je wel een compiler uit kunnen voeren (En de rest van de toolchain, assembler, linker, etc.)

[hammerhead]

Is het niet mogelijk om met builtin command read van bash iets te doen (op de een of andere manier zo de inhoud van /bin/chmod te kopieren naar een nieuw bestand dat eerst met de juiste permissies is aangemaakt, wat nog moest lukken met umask).

Weet alleen niet of read erg goed overweg kan met binary files.

[Wilke]

zomertje schreef op woensdag 21 december 2005 @ 10:08:
Ik ben ook bang dat het toch een retour colo gaat worden met een live cd. Of je moet via ssh een stukje in C kunnen schrijven dat een chmod kan uitvoeren. Maar dat mag weer niet in een programma gegoten worden want dat kan je weer niet uitvoeren Van C heb ik weinig kennis, maar ik heb wel eens leuke dingen gezien.

Mja, dat zou me nog wel lukken denk ik, en je kunt het ook op een andere machine wel compileren. Maar dan de grote vraag: hoe krijg je het daar op die machine? Als je geluk hebt werkt scp nog?

Nooit te snel wanhopen, als je even goed nadenkt zijn er vaak manieren waarop je nog wel iets kunt bereiken, maar *makkelijker* is waarschijnlijk om er gewoon heen te gaan met een live-cd.

[hammerhead]

Wilke schreef op woensdag 21 december 2005 @ 10:57:
[...]


Mja, dat zou me nog wel lukken denk ik, en je kunt het ook op een andere machine wel compileren. Maar dan de grote vraag: hoe krijg je het daar op die machine? Als je geluk hebt werkt scp nog?

Voor zover ik had begrepen werkte scp niet meer (moet namelijk nieuwe ssh sessie voor worden gestart, maakt geen gebruik van huidige SSH-sessie)

[kenneth]

Dan moet hij überhaupt nieuwe bestanden kunnen aanmaken.

[dawuss]

kenneth schreef op woensdag 21 december 2005 @ 11:01:
Dan moet hij überhaupt nieuwe bestanden kunnen aanmaken.

Dat is het probleem niet. echo is gewoon een shell command, dus echo "bla" > file maakt gewoon een nieuwe file aan. Het probleem is echter dat die file niet automagisch executable is

[hammerhead]

echter is echo ook een commando in /bin. Dus echo zal niet werken denk ik. (of is er ook een bash builtin version?)

[X-Stuff]

echo is builtin ja, maar nieuw aangemakte bestanden worden niet executable ook al geef je dit aan in de umask.

Even wat anders, is het mogelijk om een config file uit te lezen? (zonder cat dus) Dan kan ik die service in iedergeval even ergens anders draaien.

[ Voor 42% gewijzigd door X-Stuff op 21-12-2005 14:19 ]

[Buffy]

waarschijnlijk is read ook buildin dus kan je zoiets doen:

code:

while read a; do echo "$a"; done < bestand.txt

PS: Mocht je overigens nog ergens een bestand met execute permissions vinden dan kan je mbv van diet-libc hele kleine static binaries maken, bv chmod van slechts 5KB.
Deze kan je dan mbv:

code:

echo -e '\0XXX\0XXX......\0XXX' > bestand

wegschrijven naar het bestand waarbij \0XXX de octale waarden van de bytes zijn.

[ Voor 72% gewijzigd door Buffy op 21-12-2005 14:50 ]

[X-Stuff]

Dawns_sister schreef op woensdag 21 december 2005 @ 14:40:
waarschijnlijk is read ook buildin dus kan je zoiets doen:

code:

while read a; do echo "$a"; done < bestand.txt

Dat is in iedergeval gelukt, één kop zorg minder

edit:
Bedenk me zojuist nog iets, geen idee of het mogelijk is.

FTP werkt dus nog wel, maar users hebben geen toegang tot hun home dir. Is het niet mogelijk een directory bijvoorbeeld /home/xstuff te verwijderen en opnieuw aan temaken met umask 0000. Dan zit ik in iedergeval in FTP.

Heb alleen geen idee hoe je een directory zou kunnen maken zonder mkdir, maar misschien dat jullie dat wel weten.

[ Voor 42% gewijzigd door X-Stuff op 21-12-2005 15:49 ]

[zomertje]

Wilke schreef op woensdag 21 december 2005 @ 10:57:
[...]


Mja, dat zou me nog wel lukken denk ik, en je kunt het ook op een andere machine wel compileren. Maar dan de grote vraag: hoe krijg je het daar op die machine? Als je geluk hebt werkt scp nog?

Nooit te snel wanhopen, als je even goed nadenkt zijn er vaak manieren waarop je nog wel iets kunt bereiken, maar *makkelijker* is waarschijnlijk om er gewoon heen te gaan met een live-cd.

Ja, daar had ik even niet aan gedacht

[Verwijderd]

@X-Stuff: Ik denk dat je al met al minder tijd kwijt bent door gewoon ff naar je colo toe te rijden en daar een restore uit te voeren dan dat je blijft zoeken naar hobbybob oplossingen die _mogelijk_ zouden kunnen gaan werken (kan je nu al vertellen dat dat etterlijke dagen kan gaan duren btw, als het uberhaupt al gaat lukken).

[X-Stuff]

Verwijderd schreef op woensdag 21 december 2005 @ 16:22:
@X-Stuff: Ik denk dat je al met al minder tijd kwijt bent door gewoon ff naar je colo toe te rijden en daar een restore uit te voeren dan dat je blijft zoeken naar hobbybob oplossingen die _mogelijk_ zouden kunnen gaan werken (kan je nu al vertellen dat dat etterlijke dagen kan gaan duren btw, als het uberhaupt al gaat lukken).

Normaal gesproken is dat de snelste optie, maar als de toegang schaars is. Of te wel, de eigenaar van het datacenter is er bijna nooit of geen tijd heeft om toegang te geven. Het is zoals al eerder vermeld een vriendendienst, geen kosten, maar ook geen service level oid. Ideaal voor een backup server, normaal gesproken.....

Uiteraard ben ik al bezig om hem te bereiken en binnen te komen. Voor de tijd dat dat duurt is zoeken naar een mogelijke oplossing de beste manier.

[Da Fox]

doet erg denken aan rm -rf.
Weet je zeker dat er geen enkele file meer is met execute rechten?
In bovenstaand geval hadden ze een bestaande file met execute rechten overschreven met de chmod binary.

[ Voor 5% gewijzigd door Da Fox op 21-12-2005 17:06 ]

[X-Stuff]

Weet zeker dat er geen files meer aanwezig zijn met execute rechten

[Super_ik]

heb je geen tftp of telnet in inetd draaien? dan kun je mischien erwat heen tftp-en of een telnet sessie catten naar een file?

[kenneth]

En hoe moet inetd het afhandelende proces starten

[DataGhost]

TrailBlazer schreef op woensdag 21 december 2005 @ 07:56:
[...]

refereer je hier aan mijn post ifso wat klopt er dan niet aan. Jij beweert toch ook dat het een security probleem is

ja, ik refereer aan jouw post en nee, ik beweer niet dat het een security probleem is. Het is juist heel veilig, er kan niks meer uitgevoerd worden. Waar jij aan refereert is de mogelijke uitkomst van een rootkit waardoor je je systeem nooit meer kan vertrouwen, wat hier niet het geval is.

zie dit als je sleutelbos in een kluis gooien met de kluissleutel erbij en hem dan in het slot laten gaan. Niemand heeft je sleutel gekopieerd of je slot aangepast zodat meerdere sleutels passen (rootkit) maar je hebt ZELF je sleutel weggegooid en de boel op slot gedaan (chmod -x)

[Sendy]

Als er een utility is waarmee je kan hex editten, dan kan je natuurlijk "gewoon" je partitie editten . Met shell read functie kan je het filesystem dumpen naar je terminal en deze analyseren op een andere machine. Vind het execute bit van /bin/chmod en flip dit. Kopieer dat weer terug naar de machine (ftp?) en copieer dat weer (shell / echo) naar /dev/hda*.

Je hebt nog wel root toch?

edit:

Je zou bijna denken dat bash wel een built-in chmod() kan gebruiken. Of misschien BusyBox gaan draaien als root?

[ Voor 46% gewijzigd door Sendy op 22-12-2005 00:20 ]

[Zwerver]

Sendy schreef op woensdag 21 december 2005 @ 23:49:
Kopieer dat weer terug naar de machine (ftp?) en copieer dat weer (shell / echo) naar /dev/hda*.

Het is pas 10x door de TS gezegd maar goed nog een keer dan: hij kan _geen_ files meer transferen, heeft alleen nog een ssh-sessie die werkt en ook ftp werkt niet meer. Lees aub even voordat je een reply plaatst, je geeft de TS hoop terwijl de enige echte oplossing gewoon naar de colo gaan is (hoe sneu het ook is).

[Gomez12]

Welke file-read utils heb je nog wel tot je beschikking??? Want ik heb ooit eens in een soortgelijke situatie nog heel wat files gered door gewoon /dev/hda1 opnieuw te echoen met nieuwe security permissions, koste heel wat tijd en weet niet of het in huidige linux/unixen nog kan, maar was eventjes een mooie tijdelijke redding ( tot de eerste reboot want toen stonden 90% van de permissies fout, maarja klant zei dat hij maar 1x per maand ging rebooten dus datacenter bezoek stond pas over 2 weken gepland en moest ietsie pietsie naar voren geschoven worden na reboot vanuit de klant )

Oftewel.: er valt nog wel wat te redden ( schat ik ) maar een reboot zal hij nooit meer kunnen meemaken. Dus voor korte termijn werk is het nog wel (enigszins ) nuttig wat je nu aan het doen bent, maar voor lange termijn gewoon bezoek inplannen en niet rebooten voor bezoek.

[CyBeR]

Sendy schreef op woensdag 21 december 2005 @ 23:49:

edit:

Je zou bijna denken dat bash wel een built-in chmod() kan gebruiken. Of misschien BusyBox gaan draaien als root?

't rottige is dat built-ins voorrang nemen over executable-based commando's. Dus dan zou je bash moeten uitbreiden met een volledige chmod-implementatie. Maar een soort basic busybox-achtige mode ofzo zou wel handig zijn voor dit soort geintjes. Met supersimpele fallback-commando's voor dingen als chmod, chown, rm, ln, ls, etc. zodat je een fucked-up systeem waarin je nog wel een shell hebt draaien nog een beetje kunt fixen.

[TrailBlazer]

DataGhost schreef op woensdag 21 december 2005 @ 22:34:
[...]

ja, ik refereer aan jouw post en nee, ik beweer niet dat het een security probleem is. Het is juist heel veilig, er kan niks meer uitgevoerd worden. Waar jij aan refereert is de mogelijke uitkomst van een rootkit waardoor je je systeem nooit meer kan vertrouwen, wat hier niet het geval is.

zie dit als je sleutelbos in een kluis gooien met de kluissleutel erbij en hem dan in het slot laten gaan. Niemand heeft je sleutel gekopieerd of je slot aangepast zodat meerdere sleutels passen (rootkit) maar je hebt ZELF je sleutel weggegooid en de boel op slot gedaan (chmod -x)

Ik zeg ook niet dat het nu een probleem is (in ieder geval dat wilde ik niet zeggen) Ik zeg ook je krijgt je systeem nooit meer secure.. Ik bedoelde dus het is nu wel secure maar je zal het nooit meer zo secure krijgen als het was omdat je vast wel ergens een foutje maakt met de rechten van het een of ander bij het herstellen.

[ Voor 3% gewijzigd door TrailBlazer op 22-12-2005 07:48 ]

[elTigro]

CyBeR schreef op donderdag 22 december 2005 @ 07:36:
't rottige is dat built-ins voorrang nemen over executable-based commando's. (en nog meer)..

Daar heb je enable en disable voor. Ook handig, want die zijn wel built-in

[Sendy]

Zwerver schreef op donderdag 22 december 2005 @ 00:39:
[...]


Het is pas 10x door de TS gezegd maar goed nog een keer dan: hij kan _geen_ files meer transferen, heeft alleen nog een ssh-sessie die werkt en ook ftp werkt niet meer. Lees aub even voordat je een reply plaatst, je geeft de TS hoop terwijl de enige echte oplossing gewoon naar de colo gaan is (hoe sneu het ook is).

Wat een kut antwoord. Als de TS niet meer kan ftpen, dan typt-ie het filesystem maar over in z'n terminal! De TS tracht dit toch op te lossen?

[Zwerver]

Sendy schreef op donderdag 22 december 2005 @ 11:24:
[...]


Wat een kut antwoord. Als de TS niet meer kan ftpen, dan typt-ie het filesystem maar over in z'n terminal! De TS tracht dit toch op te lossen?

Het zou een kut antwoord zijn als de TS nog een andere oplossing had. Die heeft ie niet meer, hij heeft n.l. alleen nog de built in bash commando's. Je oplossing gaat daarom never nooit niet werken en volgens mij heb je voldoende ervaring om dat te weten als je de draad gelezen had. Hexeditoren moeten nou eenmaal executable zijn, want zelfs bash en sh zijn na een chmod 644/664 niet meer executable. En "even" je hele filesystem overtypen; give me a break, dat meen je toch niet serieus?

Overigens snap ik werkelijk waar niet dat we nog serieus naar een oplossing aan het zoeken zijn; de colo-walk is echt de enige optie die hij nog over heeft, alhoewel het wel geinig is om uit te zoeken wat je (indien je nog in het bezit bent van een werkende ftp/scp sessie) wel kan doen met zo'n systeem.

[kenneth]

Sendy schreef op donderdag 22 december 2005 @ 11:24:
Wat een kut antwoord. Als de TS niet meer kan ftpen, dan typt-ie het filesystem maar over in z'n terminal! De TS tracht dit toch op te lossen?

Nee, aandragen dat een fs overgetypt moet worden is behulpzaam

[X-Stuff]

SSH has just died

Ondanks dat we allemaal wel wisten dat het een "onmogelijke" missie was hebben we het toch met ze alle een goede poging gewaagd.

We weten in iedergeval nu (altans ik):
- Dat chmod evil is
- Dat het handig zou zijn als er een builtin chmod zou zijn
- Dat er een hoop behulpzame GoT-ers bij zitten die verder durven te kijken dan de handleiding.
- Dat ik mijn server ergens anders ga hosten

Bedankt allemaal!

[DeMoN]

X-Stuff schreef op donderdag 22 december 2005 @ 13:17:

- Dat je eerst 2x moet nadenken als je als root werkt en op enter wilt rammen

[Sendy]

Zwerver schreef op donderdag 22 december 2005 @ 11:45:
[...]


Het zou een kut antwoord zijn als de TS nog een andere oplossing had. Die heeft ie niet meer, hij heeft n.l. alleen nog de built in bash commando's. Je oplossing gaat daarom never nooit niet werken en volgens mij heb je voldoende ervaring om dat te weten als je de draad gelezen had. Hexeditoren moeten nou eenmaal executable zijn, want zelfs bash en sh zijn na een chmod 644/664 niet meer executable. En "even" je hele filesystem overtypen; give me a break, dat meen je toch niet serieus?

Overigens snap ik werkelijk waar niet dat we nog serieus naar een oplossing aan het zoeken zijn; de colo-walk is echt de enige optie die hij nog over heeft, alhoewel het wel geinig is om uit te zoeken wat je (indien je nog in het bezit bent van een werkende ftp/scp sessie) wel kan doen met zo'n systeem.

Tja, je kan met echo files (en dus ook filesystems) schrijven. De TS had een terminal en een shell (met echo built-in). Het is helemaal niet zo ver gezocht dat hij ook binaire data zou kunnen schrijven. En een filesystem hoeft je natuurlijk niet over te typen, hij zou het bijvoorbeeld ook in zijn terminal kunnen plakken Het zou dus best mogelijk moeten zijn.

Verder was ik natuurlijk helemaal geen praktisch (of zelf serieus) antwoord aan het geven.

Als je nog scp hebt lijkt scp -p mij trouwens de handigste oplossing

edit:

Om toch erg duidelijk te zijn. Ik schreef "kut antwoord" omdat de opmerking totaal niet constructief was. De enige melding was "LEZEN!" en dat doe ik vaak wel.

[ Voor 7% gewijzigd door Sendy op 22-12-2005 22:52 ]

[DeMoN]

Sendy schreef op donderdag 22 december 2005 @ 22:46:


Als je nog scp hebt lijkt scp -p mij trouwens de handigste oplossing

Zeg je dit nou expres of niet?

Kan me namelijk niet echt voorstellen dat je niet hebt gelezen dat dit al zo vaak afgewezen is omdat het niet meer mogelijk is dat mensen er zelfs pissing om begonnen te worden en dan kom je hiermee

[Sendy]

Jo gast. Lees de quote in mijn post nog eens. En dan vooral de laatste paar regels.

[ Voor 30% gewijzigd door Sendy op 22-12-2005 23:07 ]

[zomertje]

Houden we het wel ontopic en gezellig?

Ik kan me voorstellen dat er mensen zijn die in dit topic nog wat willen filosoferen over de mogelijkheden van de builtin commando's als je echt niets meer kan uitrichten met je systeem. Voor de TS is het al klaar, hij kan er gewoon helemaal niet meer bij op dit moment. (behalve via een retourtje colo dan)