Onderwerp: HTTP-uplinks verkeerde owner/group?

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.

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

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: nee

Hebben php-files meer rechten met user 'apache.apache' als met user 'user.user.'?

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

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/..._1_xx_mod_suid

RSBAC? Nooit van gehoord.
Google says:
Read http://www.nllgg.nl/nllgg/bijeenkoms...005/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.

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.

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.

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?

Inderdaad, aldus DirectAdmin Support (John).

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..

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/..._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?

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.

@Deimos: Op wat voor machine draai je suPHP ook in combinatie met DirectAdmin?

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.