Onderwerp: mod_suid(2)/mod_ruid ervaringen en tips

Oorspronkelijk geplaatst door bigall

Is er iemand die de frontpage server extensions, in combinatie met directadmin en mod_ruid werkend heeft?

Is er iemand die al een antwoord op deze vraag heeft gevonden ? Frontpage extensions werkend onder mod_ruid ?

Volgens mij niet, Frontpage-extensions is gewoon iets wat je niet WIL gebruiken!
Er zitten tal van bugs in en de versie die voor Apache is gemaakt is zwaar verouderd.

Als deze extensie via een eigen techniek de bestanden opvraagt kan je lang zoeken.
Want dan betekend het gewoon dat hij niet via het systeem van Apache werkt en dus andere modules gewoon negeerde.

Oorspronkelijk geplaatst door Rollerscapes

Volgens mij niet, Frontpage-extensions is gewoon iets wat je niet WIL gebruiken!
Er zitten tal van bugs in en de versie die voor Apache is gemaakt is zwaar verouderd.

Het is niet iets dat IK wil gebruiken maar ja, klanten he.... Leven met ze is moeilijk maar zonder helemaal...

je kunt natuurlijk gewoon voor deze klanten een windows server aanschaffen

Toevallig, en dat staat hier los van, zijn er al machines besteld om windows hosting aan te gaan bieden. Maar voor dit probleem is het wel een beetje een rigoreus....

Ik heb er destijds voor gekozen om frontpage niet meer te ondersteunen.
Maar niet alleen omdat het niet goed met mod_ruid werkt, maar omdat het pakket vanaf mei 2006 niet meer door Microsoft werd ondersteund, en ik nogal wat twijfels had bij de veiligheid van het pakket.

<offtopic>
Nog een tip voor de mensen die ook van de frontpage extensie af willen;
Ik kreeg het geheel niet weg uit DirectAdmin, nadat ik de module had verwijderd uit de apache configuratie.
Om frontpage uit de DirectAdmin interface te krijgen kun je gebruiken maken van de info op http://directadmin.com/features.php?id=754
</offtopic>

Ik heb zojuist het één en ander veranderd in mijn structuur. Het stond eerst wat door elkaar, nu heb ik alle virtual hosts in de home directory gezet.

Alleen krijg ik nu geen toegang meer tot mijn virtual hosts. Ik krijg een 403 error in de browser, en de volgende error staat in de error_log

Code:

[Wed Apr 30 20:45:46 2008] [error] [client <mijn-ip>] (13)Permission denied: file permissions deny server access: /home/<virtual-host>/index.html
[Wed Apr 30 21:59:21 2008] [error] [client <mijn-ip>] (13)Permission denied: access to /index.php denied
[Wed Apr 30 21:59:21 2008] [error] [client <mijn-ip>] (13)Permission denied: access to /index.html denied

Het gedeelte mbt ruid van de httpd.conf is alsvolgt:

Code:

LoadModule ruid_module        modules/mod_ruid.so

User www
Group www

De virtualhost configuratie is:

Code:

<VirtualHost *:80>
    RMode       config
    RUidGid      sanderh www
    DocumentRoot "/home/sander-h/public_html"
    ServerName sander-h.nl
    ServerAlias www.sander-h.nl
</VirtualHost>

Bij RUidGid heb ik de volgende combinaties geprobeerd:
root root, root www, www www, sanderh sanderh, sanderh root, root sanderh en www sanderh maar niets werkt.

De directory rechten van een virtual-host directory zijn 700, en de eigenaar heb ik staan op sanderh, de groep op www.

Ik word er niet goed van, maar het zal wel iets kleins zijn.. En ik hoop dat iemand me kan helpen.

Ik kreeg dit topic van iemand, dus vandaar dat ik er nog maar een bericht in plaats, aangezien er hier al zo'n lange discussie over ging..

root zal zo wie zo niet werken
De bestanden moeten op sander.www staan en ook mod_ruid ingesteld staan.

Mappen moeten op chmod 700 staan en bestanden op 600.
Wel apache herstarten he

Is er het besef dat als je de vhost onder zijn eigen user laat uitvoeren, dat die dan ook onmiddelijk write access heeft tot alle bestanden onder die DocumentRoot?

In de documentroot van de betreffende vhost bedoel je dan ? Is toch ook de bedoelding denk ik ? Anders zou apache user die rechten hebben.

Oorspronkelijk geplaatst door GlennMatthys

Is er het besef dat als je de vhost onder zijn eigen user laat uitvoeren, dat die dan ook onmiddelijk write access heeft tot alle bestanden onder die DocumentRoot?

Kan je iets duidelijker hier in zijn
Dat is toch juist de bedoeling, je wilt iedereen een eigen webruimte geven die ook onder zijn of haar account word uitgevoerd
En daar onder vallen ook schrijfrechten.

Edit:
Kennelijk ging er iets niet helemaal goed...
"Dit forum vereist dat je 60 seconden wacht tussen het verzenden van berichten. Probeer het nogmaals over 46 seconden."

Maar ik had al gepost

De ontwikkeling van mod_ruid staat al een behoorlijke tijd stil. Bugs worden niet gefixt en functionaliteit wordt niet verder uitgebreid. Op zich voldoet de module prima (mits gepatched) maar er kunnen nog veel meer leuke dingen met posix capabilities.
Afgelopen week ben ik wat aan het stoeien geweest met de module en heb de mogelijkheid toegevoegd om per virtual host een chroot omgeving in te stellen (eventueel per host verschillend). Uiteraard wordt deze na de request weer ongedaan gemaakt, zo dat een child meerder requests kan uitvoeren.

Gebruik is simpel. E.e.a. werkt exact als mod_ruid (Config is 1 op 1 uitwisselbaar). Er is alleen een optie toegevoegd:

RChrootRootDir CHROOT DOCUMENT_ROOT

Stel de documentroot was /home/virtual/domain.tld/public_html en /home/virtual moet de nieuwe root worden, dan is het toevoegen van een:

RChrootRootDir /home/virtual /domain.tld/pulblic_html

alles wat nodig is (document root optie kan vervallen bij een virtualhost).

Om verwarring met mod_ruid te voorkomen heb ik de naam van de module aangepast in mod_chruid. In de bijlage zitten twee bestanden. De source van de module en de selinux module die nodig is om httpd toe te staan een chroot functie uit te voeren.

LET op deze module is experimenteel en gebruik is geheel op eigen risico. Zelf pas ik hem op dit moment met succes toe op een centos 5.x. machine, maar dat garandeert niets voor andere configuraties.

Mocht je deze module gaan testen/gebruiken dat wordt terugkoppeling uiteraard ZEER op prijs gesteld.

Veel plezier er mee...

@Mind: ik zal wel last heb van de warmte maar ik zie die bijlagen niet meer

Oorspronkelijk geplaatst door nieuwhier

In de documentroot van de betreffende vhost bedoel je dan ? Is toch ook de bedoelding denk ik ? Anders zou apache user die rechten hebben.

Als het goed is heeft de apache user enkel lees rechten voor de web directory van de user. Met mod_ruid veranderd de apache user opeens naar de user van de klant en heeft dus opeens SCHRIJF rechten tot alle bestanden. Dit is lastig te voorkomen zonder de klant de rechten te ontnemen eigen bestanden te wijzigen. Dit is een redelijk beveiligingsrisico omdat een lek PHP script nu gegarandeerd de gehele website onderuit kan halen.

Op speciaal verzoen van Rollerscapes versie 0.2 van mod_chruid.