PDA

Bekijk Volledige Versie : HTTP-uplinks verkeerde owner/group?



Dennis
21/02/05, 14:23
Ik heb net een website toegevoegd op een nieuwe DirectAdmin-server, maar als ik plaatjes via een webformulier upload, dan kloppen de eigenaarssettings niet.

De eigenaarssettings zijn dan apache.apache terwijl ze user.user moeten zijn. Is dit een potentieel security-risk? Als de klant .php files genereert vanuit een php-file?

Tevens kan ik de apache.apache-files niet bewerken via FTP, zo ben ik erachter gekomen.

PeterT
21/02/05, 14:25
Klopt, ze krijgen de webuser permissies -> phpsuexec/suphp kan dat verhelpen en suexec voor cgi scripts.


Is dit een potentieel security-risk? Als de klant .php files genereert vanuit een php-file?

Als je box goed is beveiligd: nee


Tevens kan ik de apache.apache-files niet bewerken via FTP, zo ben ik erachter gekomen.

Even chownen dus ;)

Dennis
21/02/05, 14:30
Origineel geplaatst door PeterT
Klopt, ze krijgen de webuser permissies -> phpsuexec/suphp kan dat verhelpen en suexec voor cgi scripts.phpSuExec zou ik inderdaad kunnen overwegen. phpSuExec is iets anders dan php als perl/CGI-module draaien? Van dat laatste weet ik dat het niet geschikt is voor webhosting, het is namelijk heel traag.


Origineel geplaatst door PeterT
Even chownen dus Jah, dat snap ik.

Maar ik wil eigenlijk dat files direct de goede owner krijgen. Ik wil niet dat klanten gewoon files kunnen aanmaken met een andere user/group.


Origineel geplaatst door PeterT
Als je box goed is beveiligd: neeHebben php-files meer rechten met user 'apache.apache' als met user 'user.user.'?

PeterT
21/02/05, 14:40
Origineel geplaatst door DennisCitus
phpSuExec zou ik inderdaad kunnen overwegen. phpSuExec is iets anders dan php als perl/CGI-module draaien? Van dat laatste weet ik dat het niet geschikt is voor webhosting, het is namelijk heel traag.


Het is inderdaad iets anders, ik raad je echter eerder suPHP aan, aangezien phpSuExec bekend staat om zijn 'destructieve kwaliteiten' :)
Het is overigens een apache module; geen php mod :)


Origineel geplaatst door DennisCitus
Hebben php-files meer rechten met user 'apache.apache' als met user 'user.user.'? [/B]

Nee

Wido
21/02/05, 15:37
Wat dachten we anders van mod_suid in combinatie met rsbac/selinux?

Zo heb je alles onder de eigen gebruiker draaien zonder de php te forken via suExec :)

Wij passen het zelf met grote tevredenheid toe.

mod_suid: http://www.palsenberg.com/index.php/plain/projects/apache_1_xx_mod_suid

Dennis
21/02/05, 15:45
RSBAC? Nooit van gehoord.
Google says:
Read http://www.nllgg.nl/nllgg/bijeenkomsten/20021005/rsbac.html

SELinux? Nooit van gehoord.
Google says:
Security-Enhanced Linux, based on Fedora? O.a. Fedora Core 2 en Fedora Core 3. Gemaakt door "The National Security Agency/Central Security Service is America’s cryptologic organization.".

Interessant :)
Al betwijfel ik of het als server geschikter is dan Red Hat EnterPrise Server 3.

SELinux is alleen beschikbaar met 2.6-kernel? Hmmz...

Mod_suid is een stuk minder populair dan modSuExec... ik zal ook eens op webhostingtalk.com zoeken. :)

Dennis
22/02/05, 01:01
Antwoord
Runt php als apache-module en niet met SuPHP of als CGI-module, dan zullen alle gemaakte files automatisch apache.apache

Ik overweeg nu suPHP :)
Maar ga eerst investigaten. Ik hoor van aardig wat hosts dat ze suPHP (is wel apache-module) draaien. Maar ik hoor ook van een paar hosters dat ze phpSuExec (is onder CGI) draaien... en daardoor begin ik te twijfelen. Dat laatste vind ik niets.

Cybafish
22/02/05, 12:06
Ja, collega van me heeft hier ooit een guide geplaatst over het opzetten van suPHP, sinds dien doken er her en der weer nieuwe suPHP hosts op :)

Ik kan je verzekeren dat het niet merkbaar trager is dan PHP via de SAPI interface van apache draaien, dus maak je daar geen zorgen om.

spirit010
22/02/05, 19:08
Wij lopen tegen hetzelfde probleem aan:

Alles wat geinstalleerd word via het CMS Mambo (templates, componenten etc) krijgt als eigenaar 'apache:apache'

Hierdoor kan de gebruiker de bestanden niet wijzigen.

Als ik ze chown naar de juiste user kan die er weer alles mee doen, maar dan kan mambo het bestand niet meer wijzigen of deleten. Omdat deze als user apache werkt.

Lost suPHP dit probleem op?

Dennis
22/02/05, 22:12
Inderdaad, aldus DirectAdmin Support (John).

WH-Tim
23/02/05, 13:46
Ik heb zelf suPHP draaiende gehad en had veel problemen, te lange pathnamen die niet allowed waren, scripts die raar deden en half niet meer werkten, problemen met rechten.. ook daar dien je rekening mee te houden. Ik heb het er na enkele dagen dan ook weer eruit gesloopt..

WH-Tim
23/02/05, 14:04
Origineel geplaatst door Wido
Wat dachten we anders van mod_suid in combinatie met rsbac/selinux?

Zo heb je alles onder de eigen gebruiker draaien zonder de php te forken via suExec :)

Wij passen het zelf met grote tevredenheid toe.

mod_suid: http://www.palsenberg.com/index.php/plain/projects/apache_1_xx_mod_suid

Ik heb echt een hekel aan root user programma's, of is daarom ook die rsbac daarvoor, omdat gevaar weer te wijken?

Deimos
23/02/05, 15:04
phpSuExec zou ik inderdaad kunnen overwegen. phpSuExec is iets anders dan php als perl/CGI-module draaien? Van dat laatste weet ik dat het niet geschikt is voor webhosting, het is namelijk heel traag.
PHP als CGI is niet merkbaar trager in een standaard configuratie. Machnies van tegenwoordig zijn dusdanig snel dat een klant er niks van merkt.

Verder zie ik staan dat je het erbij phpsuexec over hebt dat je php als cgi moet draaien en bij suphp niet. Dit klopt niet bij suphp draai je php ook als cgi.

WIj draaien suphp overigens al bijna 2 jaar naar volle tevredenheid.

spirit010
23/02/05, 15:07
@Deimos: Op wat voor machine draai je suPHP ook in combinatie met DirectAdmin?

Deimos
23/02/05, 15:13
Origineel geplaatst door spirit010
@Deimos: Op wat voor machine draai je suPHP ook in combinatie met DirectAdmin?
p4 2.4 Ghz en een p3.800Mhz. Beide draaien lekker. OP beide draaien zelf ontworpen CPs.

spirit010
23/02/05, 15:14
Bedankt.

Iemand die het goed heeft draaien in combinatie met DirectAdmin (ook al DA updates vrijgeeft)

Wido
24/02/05, 12:35
Origineel geplaatst door WH-Tim


Ik heb echt een hekel aan root user programma's, of is daarom ook die rsbac daarvoor, omdat gevaar weer te wijken?

rsbac is daarvoor.

Dat draait op kernel niveau en we geven daar per user aan wie wat wel en niet mag.

De user root mag van ons gewoon helemaal niets in /home, behalve lezen.

Zo hebben we op kernel niveau alle user gejailed in hun eigen homedir.

PHP draait nu mooi als module, wat stukken sneller is dan CGI en toch draait het onder de eigen user.

Bij ons kunnen klanten ook al hun directories 700 chmodden, het blijft gewoon werken.

Hun gehele webspace draait onder hun eigen user.