Eigen apache module/plugin schrijven?

[Verwijderd]

Euj iedereen!

Gewoon voor de interesse wil ik graag een eigen apacheplugin schrijven. Stel je voor: ik heb een .ephp bestand ("Encoded PHP", eigen bedenksel). Dat is zwaar gecodeerd met een nader te bepalen algoritme (is even niet relevant).

Nu wil ik graag apache zo instellen dat hij .ephp bestanden door een bepaald (zelf te schrijven) programma uitvoert, net als dat .php bestanden door de php interpreter worden 'uitgevoerd'.

Vervolgens moet dat programma het .ephp bestand decrypten naar een .php bestand zodat het door php uitgevoerd kan worden. En vervolgens moet php z'n output geven aan apache die het weer naar de client doorspeelt!

Misschien denk ik een beetje simpel, maar kan iemand me op weg helpen? Waarin moet ik zo'n programma schrijven? Kan ik dat programma op een webserver zetten waar ik geen root-rechten heb (dus bijv. bij XS4all), en dan een lokale configuratie (.htaccess) aanmaken waarin de extensie .ephp gekoppeld wordt aan mijn programma? En hoe zorg ik dat mijn programma php uitvoert op het net gedecodeerde script en dat de output van php weer naar apache toegaat?

Uiteindelijk gaat het er dus om dat ik een eigen manier maak om .php bestanden te coderen, zodat anderen er niet zomaar met m'n source vandoor kunnen gaan. Ik heb al bestaande alternatieven geprobeerd, maar ik schrijf 'm ivm de kosten en ervaring liever zelf! Alvast bedankt!

[rollebol]

Ik denk dat je beter een patch kan maken op PHP. Waarschijnlijk is dat niet alleen eenvoudiger, maar levert het ook een betere performance. Op de manier die jij voor ogen hebt zal je PHP waarschijnlijk aan moeten roepen als CGI. Dat wordt algemeen als inefficient beschouwd (maar op kleine schaal kan het ook weer niet veel kwaad).

[Defspace]

Simpelste antwoord: Stap over op Coldfusion

Je schrijft zo'n module normaal gesproken in c(++).
Er is op het web o.a. bij Apache behoorlijk wat informatie te vinden over het schrijven van modules.
Nee volgens mij krijg je het zonder root (apache config) rechten niet voor elkaar om deze module bij b.v. XS4all te laten draaien.
De rest moet wel te doen zijn.

[Emmeau]

in apache een andere handler aan ephp koppelen die een door jouw gemaakt programma aanroept wat vervolgens:
1) het ephp bestand decodeerd
2) het gedecodeerde bestand door php haalt

[Verwijderd]

Emmeau schreef op 22 September 2003 @ 16:46:
in apache een andere handler aan ephp koppelen die een door jouw gemaakt programma aanroept wat vervolgens:
1) het ephp bestand decodeerd
2) het gedecodeerde bestand door php haalt

Maar kan ik die handler dan dmv een .htaccess bestand (dus zonder rootrechten) in m'n htdocs dir koppelen aan m'n .ephp bestanden?

[ Voor 20% gewijzigd door Verwijderd op 22-09-2003 16:49 ]

[Glashelder]

Effe offtopic maar hoe kunnen andere mensen nou met je source ervandoor gaan? PHP code is toch nooit zichtbaar in de geparste pagina? Hier niet iig



Als ik dit topic zo zie lijkt het me niet mogelijk

[ Voor 29% gewijzigd door Glashelder op 22-09-2003 16:52 ]

[Verwijderd]

dual-zip schreef op 22 September 2003 @ 16:51:
Effe offtopic maar hoe kunnen andere mensen nou met je source ervandoor gaan? PHP code is toch nooit zichtbaar in de geparste pagina? Hier niet iig

Als jij niet beheerder van de machine bent, dan kan er altijd minimaal 1 persoon extra bij jouw sourcecode komen.

[rollebol]

dual-zip: Op de server zelf kan je vaak wel de PHP source raadplegen van anderen. Vaak ook niet overigens.

[Verwijderd]

rollebol schreef op 22 september 2003 @ 16:53:
dual-zip: Op de server zelf kan je vaak wel de PHP source raadplegen van anderen. Vaak ook niet overigens.

Dan zijn permissies gewoon erg slecht ingesteld door betreffende persoon cq administrator

[rollebol]

Verwijderd schreef op 22 September 2003 @ 16:55:
[...]


Dan zijn permissies gewoon erg slecht ingesteld door betreffende persoon cq administrator

Klopt.

Maar in het laatste geval is daar vaak weinig aan te doen. Een bestandje met naam en wachtwoord onleesbaar maken kan meestal wel, maar de source kan niet in alle gevallen eenvoudig beschermd worden van 'de buren'.

[ Voor 34% gewijzigd door rollebol op 22-09-2003 16:58 ]

[Verwijderd]

Jawel hoor. Als de administrator op de webroot van de user gewoon rechten zet als 750 en op bestanden 640 met bijbehorende usernaam:apache-user dan kan niemand buiten de admin en jijzelf erbij.

Dit behoort gewoon in de ftp-server ingesteld te worden, zodat deze permissies automatisch toegekend worden aan bestanden/dirs die ge-upload worden naar de webroot van de betreffende user.

[ Voor 3% gewijzigd door Verwijderd op 22-09-2003 17:03 ]

[Verwijderd]

Het is niet mogelijk om bij de 'buren' te lezen. Dat is het probleem niet. Het gaat erom dat mijn php source op een externe server komt (dus van een iemand die ik niet volledig vertrouw). Ik wil niet dat hij/zij zomaar via ftp op zijn eigen site mijn .php scriptjes jat!
Daarom wil ik graag zelf een encryptie-plugin schrijven.

[rollebol]

Verwijderd schreef op 22 september 2003 @ 17:03:
Jawel hoor. Als de administrator op de webroot van de user gewoon rechten zet als 750 en op bestanden 640 met bijbehorende usernaam:apache-user dan kan niemand buiten de admin en jijzelf erbij.

Dit behoort gewoon in de ftp-server ingesteld te worden, zodat deze permissies automatisch toegekend worden aan bestanden/dirs die ge-upload worden naar de webroot van de betreffende user.

Natuurlijk kan het wel, maar dat wil niet zeggen dat het ook zo is. Er zijn genoeg web hosts waar je bij de files van de buren kan. Soms is dat zelfs een design-keuze. Maar als klant heb je daar weinig invloed op.

Verder heeft een FTP-server natuurlijk niet per se iets te maken met de apache-groep. Als ik files in mijn homedir zet (dus niet mijn public_html of zo) dan wil ik helemaal niet dat de apache-user die files kan lezen.

[ Voor 14% gewijzigd door rollebol op 22-09-2003 17:14 ]

[Verwijderd]

Maar we gaan er op dit moment nog even vanuit dat de buren er niet bij kunnen. Ik wil slechts weten hoe ik apache met een .htaccess bestand kan vertellen dat hij .ephp bestanden moet openen met het programma "decode_ephp".

[mocean]

Ik heb geen echte inhoudelijke oplossing helaas.

Wel zou een dergelijke plugin/module volgens mij zeer interessant zijn (als je een niet al te grote fan van opensource bent). Je kan dan ook een complete webapplicatie in een so file bouwen, en dan in php alleen dat object even activeren.

In coldfusion en het ASP framework is dat allemaal beter te doen (of gebruikelijker), maar we zitten in NOS. Is zo'n module eigenlijk platform onafhankelijk te maken?

[Verwijderd]

Kijk hier eens:
http://www.zend.com/store/products/zend-encoder.php
http://www.sourceguardian.com/products/phppro.htm
http://scriptstoprofit.com/codelock.php

[ Voor 44% gewijzigd door Verwijderd op 22-09-2003 18:52 ]

[Bananenplant]

nergens om.... maar is het eigenlijk wel zinvol om te encrypten en de sleutel alsnog op de plek te laten waar de beheerder van de bak bijkan?

[igmar]

Verwijderd schreef op 22 September 2003 @ 17:03:
Jawel hoor. Als de administrator op de webroot van de user gewoon rechten zet als 750 en op bestanden 640 met bijbehorende usernaam:apache-user dan kan niemand buiten de admin en jijzelf erbij.

Dit behoort gewoon in de ftp-server ingesteld te worden, zodat deze permissies automatisch toegekend worden aan bestanden/dirs die ge-upload worden naar de webroot van de betreffende user.

En wat belet mij met een CGI / PHP script om de hele webroot leeg te trekken ? Zolang Apache onder een common user draait is er weinig aan te doen...

[PipoDeClown]

Verwijderd schreef op 22 september 2003 @ 17:30:
[..] dat hij .ephp bestanden moet openen met het programma "decode_ephp".

ik wil niet rot doen maar twijfel of je uberhaupt in bijv. de installatie doc van php heb gelezen.

code:

ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"

(tis voor windows maar dat mag de pret niet drukken).
cq. de documentatie voor betreffende configuratie items in de apache docs.

oftewel je moet de apache install httpd.conf aanpassen om je idee te laten werken.
waar je uiteraard de rechten voor moet hebben.
.htaccess is geen lokale apache configuratie.

en wellicht kun je dan ook zelf in de betreffende docs kijken hoe je modules devt.

[ Voor 26% gewijzigd door PipoDeClown op 22-09-2003 19:06 ]

[Verwijderd]

PipoDeClown schreef op 22 September 2003 @ 19:02:
[...]

ik wil niet rot doen maar twijfel of je uberhaupt in bijv. de installatie doc van php heb gelezen.

code:

ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"

(tis voor windows maar dat mag de pret niet drukken).
cq. de documentatie voor betreffende configuratie items in de apache docs.

euh, en dan kan php.exe zomaar willekeurig gecodeerde source's ontcijferen dan?

ik vraag me af of jij wel de Startpost hebt gelezen

[ Voor 9% gewijzigd door Verwijderd op 22-09-2003 19:05 ]

[elevator]

Verwijderd schreef op 22 september 2003 @ 16:41:
Euj iedereen!

Heeeuuhh!!!!

Gewoon voor de interesse wil ik graag een eigen apacheplugin schrijven. Stel je voor: ik heb een .ephp bestand ("Encoded PHP", eigen bedenksel). Dat is zwaar gecodeerd met een nader te bepalen algoritme (is even niet relevant).

Nu wil ik graag apache zo instellen dat hij .ephp bestanden door een bepaald (zelf te schrijven) programma uitvoert, net als dat .php bestanden door de php interpreter worden 'uitgevoerd'.

2 manieren, basically.

• Je schrijft een eigen Apache module. Als je de Apache source download zit daar een mod_example in, deze kan je vrij gemakkelijk aanpassen, een handler eraan en klaar (iets versimpelde weergave ). Nadeel is dat je om modules te mogen laden in Apache, je de config file moet kunnen aanpassen. Uiteraard.
• Associate je PHP files met een CGI handler, die CGI handler laat je een wrapper zijn om de standaard PHP CGI handler, en je handelt het op die manier af.

2e manier is veruit het gemakkelijkste.

[Verwijderd]

rollebol schreef op 22 september 2003 @ 17:12:
Verder heeft een FTP-server natuurlijk niet per se iets te maken met de apache-groep. Als ik files in mijn homedir zet (dus niet mijn public_html of zo) dan wil ik helemaal niet dat de apache-user die files kan lezen.

Ik geloof toch echt dat er duidelijk in de webroot stond

Daarnaast kan de user waar apache onderdraait sowieso niet inloggen, dus een echte ramp is het nou ook weer niet. Tenminste als je home-dirs niet worldreadable zijn dan

igmar schreef op 22 September 2003 @ 18:55:
[...]


En wat belet mij met een CGI / PHP script om de hele webroot leeg te trekken ? Zolang Apache onder een common user draait is er weinig aan te doen...

Niets.

Alleen dan moet je al iets meer moeite doen

[ Voor 23% gewijzigd door Verwijderd op 22-09-2003 23:17 ]

[Verwijderd]

Maar als ik het dus goed begrijp is dit alles niet te doen als ik geen root-rechten heb, maar slechts user-rechten?

[Mark]

igmar schreef op 22 september 2003 @ 18:55:
[...]


En wat belet mij met een CGI / PHP script om de hele webroot leeg te trekken ? Zolang Apache onder een common user draait is er weinig aan te doen...

En daar hebben we dus bijvoorbeeld open_basedir voor in PHP en suexec voor CGI. Als je het goed inricht kan user A dus absoluut niets doen in de webdir van user B. Het kost alleen wat tijd om zoiets in te richten.

[GiLuX]

Mark schreef op 23 september 2003 @ 14:33:
[...]

En daar hebben we dus bijvoorbeeld open_basedir voor in PHP en suexec voor CGI. Als je het goed inricht kan user A dus absoluut niets doen in de webdir van user B. Het kost alleen wat tijd om zoiets in te richten.

naja, wat tijd?
hoeveel tijd kost het iemand om dit in een apache conf te typen?
php_admin_value open_basedir "/eendir/:/een/andere/dir/"

enige nadeel is dat openbase dir tot de dag van vandaag buggy is,
maw, als je hier aan begint moet je in iedere virtualhost directive (als je die gebruikt) een openbasedir meegeven anders loop je kans dat een site die het niet in zijn directive heeft staan begint te zeuren dat hij een openbase dir restrictie heeft al is dat helemaal niet zo.
maar goed, afgezien van die bug is het een prima middel om iemand binnen zijn toegewezen directory te houden.

als het puur om versleutelen van php code gaat dan zijn er idd legio opties om dat te doen, bv commercieel met zend encoder of gratis met turck mmcache

en als je zo nodig een module wil schrijven, schrijf dan een php module.
als je C kan programmeren moet dat volgens mij niet al te lastig zijn.
er staat een howto op zend.com

[Mark]

GiLuX schreef op 23 September 2003 @ 18:15:
[...]


naja, wat tijd?
hoeveel tijd kost het iemand om dit in een apache conf te typen?
php_admin_value open_basedir "/eendir/:/een/andere/dir/"

PHP is inderdaad vrij makkelijk, ik doel eigenlijk ook meer op suexec. Al is dat ook vrij makkelijk als je mooie scriptjes hebt voor het toevoegen van nieuwe sites. In het maken van zo'n script zit ook de meeste tijd (al levert dit op den duur wel een flinke besparing op).

enige nadeel is dat openbase dir tot de dag van vandaag buggy is,
maw, als je hier aan begint moet je in iedere virtualhost directive (als je die gebruikt) een openbasedir meegeven anders loop je kans dat een site die het niet in zijn directive heeft staan begint te zeuren dat hij een openbase dir restrictie heeft al is dat helemaal niet zo.

Ik ben tot op heden nog nooit tegen een bug aangelopen hierin. Ik gebruik dan echter wel overal netjes basedir directives in mijn virtualhost directives.