PDA

Bekijk Volledige Versie : vragen: php 'safemode' & 'fair use' dataverkeer



David
07/11/03, 16:13
...

wdv
07/11/03, 16:47
PHP safe_mode is absoluut geen probleem. Het is een functie van PHP om er voor te zorgen dat PHP veilig blijft in een virtual hosting omgeving (meerdere domeinen op 1 server).

Fair use is absoluut fout! Juist omdat niet vast staat hoeveel dataverkeer je mag verbruiken kunnen ze je er vaak op pakken en nog extra geld vragen voor "overmatig dataverbruik".

Deimos
07/11/03, 16:49
Fair use houdt in dat je niet meer mag verbruiken dan de gemiddelde gebruiker bij de host. Wat dit dus is is niet te zeggen en ik raad je dan ook aan dat je ene host kiest met "harde" limieten.

Wat betreft safe_mode dit leverd normaal gesproken geen problemen mits de programmeur zich netjes aan de regels van PHP heeft gehouden. Het kan dus wel voorkomen, dat een script niet functioneerd.

rq
07/11/03, 17:30
Deimos,

safe_mode kan wel degelijk problemen opleveren ook al houdt de programmeur zich netjes aan de regels. Sommige functies worden in safe_mode namelijk gewoon 'gedisabled'.

wdv
07/11/03, 18:44
Origineel geplaatst door rq
Deimos,

safe_mode kan wel degelijk problemen opleveren ook al houdt de programmeur zich netjes aan de regels. Sommige functies worden in safe_mode namelijk gewoon 'gedisabled'.

Dit zijn voornamelijk systeem functies, die normaal gesproken ook niet voor virtual host users bedoelt zijn :)

Rick L.
07/11/03, 22:32
Waarschijnlijk bieden ze ook wel de mogelijkheid om safemode eventueel uit te zetten als jij hierom vraagt. Lijkt me ten minste wel zo logisch...

electric
07/11/03, 22:39
Origineel geplaatst door Cyberboy
Waarschijnlijk bieden ze ook wel de mogelijkheid om safemode eventueel uit te zetten als jij hierom vraagt. Lijkt me ten minste wel zo logisch...

lijkt me wel gemakelijk te doen, je kan nml in de apache config per virtualhost instellen of deze php_safemode draait of niet e.d. :)

roland
08/11/03, 01:55
Er zijn verschrikkelijk veel functies die niet werken als PHP in safe mode draait.

- Denk aan alle systeem functies
- een uitgebreide file manager zal niet werken (read/write/chmod/fwite,etc)
- geeft problemen als je in een include bestand een andere include laadt (is ook weer afhankelijk van een aantal instellingen)

het is geen probleem als je een simpele site hebt. Als je echter een zeer uitgebreidt systeem/website hebt zal je problemen krijgen. Als een host PHP in safe mode ondersteund krijg je niet de hele versie van PHP, maar een "half" product.

Het maakt niet uit hoe netjes je aan de regels houdt, veel (voor mij belangrijke) dingen zullen dan niet werken.

EgoH
08/11/03, 02:06
Origineel geplaatst door roland
een aantal instellingen)

het is geen probleem als je een simpele site hebt. Als je echter een zeer uitgebreidt systeem/website hebt zal je problemen krijgen. Als een host PHP in safe mode ondersteund krijg je niet de hele versie van PHP, maar een "half" product.


Safemode staat meestal aan zodat andere klanten niet bij jouw bestanden kunnen komen. Safemode uitzetten en php draaien als module is niet erg slim lijkt me....

cedric
08/11/03, 02:37
Origineel geplaatst door EgoH


Safemode staat meestal aan zodat andere klanten niet bij jouw bestanden kunnen komen.
Daarvoor hoef je niet de grote middelen uit te halen hoor :)

Er is ook een open_basedir restrictie die ingeschakeld kan worden.
Daar kun je specifiëren welke directories de gebruiker toegang tot heeft.

Nog leuker is het om php.cgi onder suexec te gaan draaien (mits inleveren van enkele "mogelijkheden").

Dennis
08/11/03, 10:47
Beste Cedric,

Wat bedoel je precies met 'nog leuker'?
Beter of 'Absoluut niet doen!'?

Deimos
08/11/03, 11:21
php als cgi werkt perfect. Draaien het nu hier ook en geen gedonder meer met functies die niet werken en alles draait onder het uid / gid van de user van de scripts. Nu kunnen we malafide scripts nog makkelijker herkennen, aangezien elke mail die onze server verlaat het uid / gid van de orginele aanroeper meegeeft. Tevens kan je leuke stats er van maken. Ook klopt nu de quotas en kan de user zelf files deleten via ftp die via het www zijn geupload (kan normaal met php niet, want die bestanden zijn van dezelfde eigenaar als apache).

wdv
08/11/03, 11:23
Origineel geplaatst door Deimos
php als cgi werkt perfect. Draaien het nu hier ook en geen gedonder meer met functies die niet werken en alles draait onder het uid / gid van de user van de scripts. Nu kunnen we malafide scripts nog makkelijker herkennen, aangezien elke mail die onze server verlaat het uid / gid van de orginele aanroeper meegeeft. Tevens kan je leuke stats er van maken. Ook klopt nu de quotas en kan de user zelf files deleten via ftp die via het www zijn geupload (kan normaal met php niet, want die bestanden zijn van dezelfde eigenaar als apache).

Hoe geef jij dan het uid/gid mee in een mail?

Deimos
08/11/03, 11:38
In exim doe ik dat dmv volgende regels in de dns lookup config in het router gedeelte van de exim config.

headers_add = "X-AntiAbuse: This header was added to track abuse, please include it with any abuse report\n\
X-AntiAbuse: Primary Hostname - $primary_hostname\n\
X-AntiAbuse: Original Domain - $original_domain\n\
X-AntiAbuse: Originator/Caller UID/GID - [$originator_uid $originator_gid] / [$caller_uid $caller_gid]\n\
X-AntiAbuse: Sender Address Domain - $sender_address_domain\n\
X-AntiAbuse: Please mail abuse mails to: abuse@starhost.nl\n"

EgoH
08/11/03, 11:50
Origineel geplaatst door cedric

Daarvoor hoef je niet de grote middelen uit te halen hoor :)

Er is ook een open_basedir restrictie die ingeschakeld kan worden.
Daar kun je specifiëren welke directories de gebruiker toegang tot heeft.

Nog leuker is het om php.cgi onder suexec te gaan draaien (mits inleveren van enkele "mogelijkheden").

openbasedir heb je dus eigenlijk niks aan.
De shell commando's worden dan dus niet gelocked in die directory.
Kunnen ze dus nog hele server bekijken...

De performance van cgi is toch heel wat minder tegenover de php module..

Deimos
08/11/03, 12:05
Performance verschil valt me alles mee en ach heb liever een server die iets minder sites draait dan één met php safemode, maar dat is mijn opinie. :)

wdv
08/11/03, 12:12
Overigens is safe_mode veel minder erg als je alles onder eigen uid/gid heb draaien, dan maken al die uid/gid checks niet meer uit, want die gaan gewoon goed :)

EgoH
08/11/03, 12:16
Origineel geplaatst door Deimos
Performance verschil valt me alles mee en ach heb liever een server die iets minder sites draait dan één met php safemode, maar dat is mijn opinie. :)

Nou er wordt altijd veel verschil gemaakt met VS<->NL van ping verschil van 100ms.
Als je php als cgi draait krijg je dus ook al 100ms vertraging tegenover module.
Wij draaien php standaard als module met safemode, met htaccess kan je het als cgi laten draaien met safemode uit.
Dan wordt de cgi ook gechroot in je eigen directory dus kunnnen ze nooit bij bestanden van andere klanten komen.

Cybafish
08/11/03, 14:08
Wij hadden aardig wat problemen met phpsuexec helaas.. ik weet niet in hoeverre dit veranderd is in de afgelopen anderhalve maand maar toen wij het draaiden zag ik regelmatig "Internal Server Error" op de sites die van php gebruik maakten. (met name invision board). Als ik dan in de log files van apache ging kijken stond er iets over de headers (ben vergeten wat het precies was helaas)

Iemand met hetzelfde probleem?

[edit] Error was als volgt:


[error] [client: <ip>] Premature end of script headers: <path naar script>

Deimos
08/11/03, 15:26
Ik heb nergens staan dat wij php draaien met suexecphp ;). We gebruiken www.suphp.org

Cybafish
08/11/03, 15:53
Hmm, ik ben het weer eens gaan proberen allemaal en het was eigenlijk een best domme fout.. :x

Er waren een heleboel files die bijvoorbeeld van user nobody (apache) waren of van user root (als ik iets ging installen met een untar bijv.)


chown <username>:<groep> *

lost dit op :)

The MAzTER
08/11/03, 16:20
...

Cybafish
08/11/03, 17:26
Zo, ik heb zojuist ondervonden dat het voor geen méter werkt, phpsuexec. Suphp daarintegen werkt pérfect :o

Ik maak wel een install guide en post hem op 't forum :)

The MAzTER
08/11/03, 18:05
...

reneovertoom
08/11/03, 19:13
Mooi werk :) Zeer interessant, ik ben erg benieuwd ! :)

cedric
09/11/03, 19:24
Ik heb een server draaien met php onder suexec. Werkt netjes :)

Gebouwd met de patches op http://www.localhost.nl/

Bijna alle kant-en-klare scripts (zoals phpbb, phpnuke, postnuke, etc) werken perfect.

Je moet er wel voor zorgen dat de phpscripts en de directories waarin deze zich bevinden niet beschrijfbaar zijn voor anderen dan de user waaronder het script draait. (maw het zijn gewoon de limiteringen zoals je die hebt als je gewone cgi-scripts onder suexec draait).

Voor de rest heb je het nadeel dat je geen php_value of php_flag kunt gebruiken (of php_admin_value/flag) in je apache conf of .htaccess.

Cybafish
09/11/03, 19:42
Tja, om even op de vraag van de topicstarter in te gaan:

1. PHP safemode is nergens voor nodig, een beetje professionele hoster weet hoe hij zn servers veilig kan maken zonder safe-mode.

2. Fair Use policy is naaierij, je weet nooit wat je te wachten staat.

Deimos
09/11/03, 19:45
Origineel geplaatst door The MAzTER
suPHP lijkt me wel een optie, maar staat nog in een begin fase. Waaruit concludeer je dit als ik mag vragen?

The MAzTER
09/11/03, 20:14
...

wdv
09/11/03, 20:23
Origineel geplaatst door The MAzTER
Geen idee wat voor bugs etc er nog in kunnen zitten en in hoeverre het getest is.

Ik moet de eerste bug nog tegenkomen..

Cybafish
09/11/03, 23:25
Origineel geplaatst door The MAzTER


beetje verkeerd geformuleerd misschien.

maar wat ik bedoel is: het zit nog in een beta stadium (teminste dat neem ik aan aangezien versie nummers met 0.x.x beginnen). Geen idee wat voor bugs etc er nog in kunnen zitten en in hoeverre het getest is.

dat is een beetje wat ik daarmee bedoelde ;)

ik ben namelijk niet iemand die het eerste beste script wat ik tegen kom direct installeer.

Ik ook niet, laat staan dat ik er een guide voor schrijf ;)

The MAzTER
10/11/03, 00:22
...