...
Likes: 0
Laatst gewijzigd door David; 17/12/04 om 20:52.
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".
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.
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 zijnOrigineel 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'.![]()
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.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...![]()
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.
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....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.
Daarvoor hoef je niet de grote middelen uit te halen hoorOrigineel geplaatst door EgoH
Safemode staat meestal aan zodat andere klanten niet bij jouw bestanden kunnen komen.
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").

Beste Cedric,
Wat bedoel je precies met 'nog leuker'?
Beter of 'Absoluut niet doen!'?
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?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).
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"
openbasedir heb je dus eigenlijk niks aan.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").
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..
Laatst gewijzigd door EgoH; 08/11/03 om 11:53.