Bekijk Volledige Versie : install & config Mod_ruid
Ik heb altijd su_php gebruikt maar aangezien dat toch bepaalde problemen met zich meebrengt ( geen accelerators bijv ).
Zit ik te kijken naar mod_ruid ik heb deze uit het volgende topic
( http://www.webhostingtalk.nl/scripting-en-programmeren/153510-mod_ruid-nieuwe-ontwikkelingen.html )
Kan iemand mij vertellen hoe ik deze op een Directadmin server krijg? Want ik kan verder niets vinden over hoe ik hem installeer of instel.
Je maakt 35 euro over met Paypal naar randy@aklmedia.nl en hij doet de rest :lovewht:
Ik ga even van EL5 uit. Op Debian is het eerste regeltje anders. (yum == apt-get en de module heet gewoon libcap)
Onderstaand is copy, paste & pray...
yum install libcap-devel
cd /usr/src
wget http://websupport.sk/~stanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz (http://websupport.sk/%7Estanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz)
tar -xzf mod_ruid-0.6b.tar.gz
cd mod_ruid-0.6b
/usr/sbin/apxs -a -i -l cap -c mod_ruid.c
cd /usr/local/directadmin/data/templates
cp virtual_host2* custom/
cd custom
wget http://crew.pcextreme.nl/files/linux/util/directadmin/da_vhosts_templates_apache2_mod_ruid.tar.gz
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm -f da_vhosts_templates_apache2_mod_ruid.tar.gz
nano /etc/httpd/conf/httpd.conf
Voeg toe boven "ServerAdmin admin@localhost": (Verander dit meteen even naar je eigen adres)
# mod_ruid
RMode config
RUidGid apache apache
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
Dat ga ik eens uittesten. ;)
Ik probeer het eerst liever zelf zodat ik weet wat er gebeurd. Mocht het niet lukken komt die 35 euro alsnog jou kant op randy :)
Ik neem aan dat het met die versie van Mind op dezelfde manier werkt het installeren. :)
Aangezien ik mijn eigen post niet meer aan kan passen, hoe kan ik zien of mod_ruid ook daadwerkelijk werkt?
Door de zoekfunctie te gebruiken: http://www.webhostingtalk.nl/technische-vragen-van-beginners/156667-mod_ruid-maar-ik-zie-toch-apache-staan.html
Inderdaad, dat had ik dus moeten doen :sweatdrop:->|
Het werkt in ieder geval :thumbup: Bedankt Randy :thumbup:
Inderdaad, dat had ik dus moeten doen :sweatdrop:->|
Het werkt in ieder geval :thumbup: Bedankt Randy :thumbup:
Nu nog wel de rechten homedirs even goed zetten opdat er geen apache-bestanden meer zijn. Dat kan met de hand, dat kan nog makkelijker met een script dat bij DA zit:
cd /usr/local/directadmin/scripts && ./set_permissions.sh user_homes
Oh daar was dus een script voor ->|
En ik alles maar met de hand doen :p
Ach ja weer wat geleerd :)
Wat ik trouwens wel gemerkt heb. Toen ik op een map de volgende regels uitvoerde:
find /home/<user>/ -type d -print0 | xargs -0 chmod 700
find /home/<user>/ -type f -print0 | xargs -0 chmod 600
Werkt het vervolgens perfect :) Geen gezeik met rechtenkwesties ed. Maar wanneer ik doe:
find /home/ -type d -print0 | xargs -0 chmod 700
find /home/ -type f -print0 | xargs -0 chmod 600
Dan krijg ik bij alle domeinen op de server een forbidden melding.
Is dit op een manier op te lossen? Want elke user apart gaan doen zie ik nu ook weer niet zo zitten ;)
Zo ingewikkeld hoeft het niet te zijn...
find /home/*/ en de rest van je regel
en 0664 en 0755 lijkt me handiger.
Zo ingewikkeld hoeft het niet te zijn...
find /home/*/ en de rest van je regel
en 0664 en 0755 lijkt me handiger.
waarom wil je bestanden zowel op gebruiker als op groep lees en schrijfrechten geven? Die gebruiker is tevens z'n eigen groep dus dat lijkt me een beetje onzinnig. ;) Maar ik kan het mis hebben, zit hier een reden achter?
Randy, in hoeverre baken jij af dat de functionaliteiten van mod_ruid niet misbruikt worden om root te worden? Denk aan het risico van Apache exploits (momenteel geen issue natuurlijk, maar wat als er een 0-day exploit toegepast wordt, gefocussed op mod_ruid users?), of misbruik van de POSIX functies van PHP.
De mod_ruid module is interessant, maar als ik zo de reacties op WHT lees van verschillende leden heb ik de indruk dat velen niet realiseren dat het ook weer nieuwe security issues introduceert die goed afgeschermd moeten worden (wat overigens ook in de README staat).
Wouter,
Ik heb er geen problemen mee. het 'master' Apache proces draait ook als root. Met de 777-ellende, allow_url_fopen én een oude Joomla installatie die te vinden is op iedere drukke shared server heb je meer problemen.
Voordeel van mod_ruid is ook dat je 'bagger' in de /tmp meteen kunt traceren doordat deze van de user zijn en niet van apache. Al zet ik sessies standaard in memcached.
Geen problemen gehad met exploits of what so ever. Wel weet ik dat een enkeling problemen heeft met de oude, ongepatche versie van mod_ruid (niet die van Kees hier (http://www.webhostingtalk.nl/scripting-en-programmeren/153510-mod_ruid-nieuwe-ontwikkelingen-2.html) op het forum). Misschien dat iemand hier nog een toelichting op kan geven?
Trouwens, jij nog een uurtje BSD-tijd voor me deze week? :)
Ok duidelijk. Die 'ellende' blijft ook zonder mod_ruid binnen de perken, de enige reden dat het mij interessant lijkt is wat rechten-issues voorkomen (bestandjes die van apache zijn en niet meer verwijderd kunnen worden, dat soort gedoe).
En, je weet me te vinden ;-)
Ik heb het nu ook thuis om mijn testbak draaien, maar ik had daarstraks een script waarvan ik de map eerst 771 moest chmodden anders bleef ik filepermissie fouten krijgen. Als ik een whoami doe op de browser geeft hij wel de goede gebruiker aan.
Blijf je dat toch houden bij sommige scripts? Of heb ik iets in de config verkeerd staan?
Randy, in hoeverre baken jij af dat de functionaliteiten van mod_ruid niet misbruikt worden om root te worden? Denk aan het risico van Apache exploits (momenteel geen issue natuurlijk, maar wat als er een 0-day exploit toegepast wordt, gefocussed op mod_ruid users?), of misbruik van de POSIX functies van PHP.Van het feit dat de php posix functies zijn te misbruiken heb ik nooit bewijs gezien (kan naar mijn mening ook niet).
De enige echt grote blunder die je met php kan maken is het toestaan van de dl() functie op een server met mod_ruid. Je kan dan een module uitvoeren waarmee je in no time root bent.
Een 0-day exploit is een risico, maar dit kan je met bv. SElinux aardig afschermen.
Het mooie van de mod_ruid implementatie is dat je een UID/GID bepaalt, dan controleert of die niet 0 is, en dan het OS vraagt het proces hiernaar over te zetten. Het is echt maar 3 regels code ofzo en heel rechtlijnig.
Mod_ruid werkt overigens ongeacht of je een php, html of wat dan ook bestand opvraagt. Bij iedere request wordt het uitgevoerd voordat al die andere code wordt aangeroepen. De kans dat het downstream proces invloed heeft op mod_ruid is nul.
martinvandebelt
25/07/10, 20:43
Je maakt 35 euro over met Paypal naar randy@aklmedia.nl en hij doet de rest :lovewht:
Ik ga even van EL5 uit. Op Debian is het eerste regeltje anders. (yum == apt-get en de module heet gewoon libcap)
Onderstaand is copy, paste & pray...
yum install libcap-devel
cd /usr/src
wget http://websupport.sk/~stanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz (http://websupport.sk/%7Estanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz)
tar -xzf mod_ruid-0.6b.tar.gz
cd mod_ruid-0.6b
/usr/sbin/apxs -a -i -l cap -c mod_ruid.c
cd /usr/local/directadmin/data/templates
cp virtual_host2* custom/
cd custom
wget http://crew.pcextreme.nl/files/linux/util/directadmin/da_vhosts_templates_apache2_mod_ruid.tar.gz
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm -f da_vhosts_templates_apache2_mod_ruid.tar.gz
nano /etc/httpd/conf/httpd.conf
Voeg toe boven "ServerAdmin admin@localhost": (Verander dit meteen even naar je eigen adres)
# mod_ruid
RMode config
RUidGid apache apache
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
Mocht iemand bovenstaand script gebruiken om mod_ruid te installeren, let er dan op dat de nieuwe Multi IP-feature (ipv6 ondersteuning) in DirectAdmin niet werkt. Dit omdat de custom templates niet geupdate zijn.
Ik heb de templates geupdate, dus mag je zie hier downloaden:
http://exaweb.dk/uploads/da_vhosts_templates_apache2_mod_ruid.tar.gz
Installatie als je de templates van pcextreme gebruikt (update van je custom templates):
cd /usr/local/directadmin/data/templates/custom
wget http://exaweb.dk/uploads/da_vhosts_templates_apache2_mod_ruid.tar.gz
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm -f da_vhosts_templates_apache2_mod_ruid.tar.gz
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
Yourwebhoster
25/07/10, 21:50
Hier heb je iets beters, lost gelijk je probleem met de permissies op:
cd /usr/local/directadmin/data/templates/custom
wget http://mirror.yourwebhoster.eu/vhosts.tar.gz
tar -xzf vhosts.tar.gz
rm -f vhosts.tar.gz
echo “action=rewrite&value=httpd” >> /usr/local/directadmin/data/task.queue
Even een klein schopje.
Ik vroeg me af hoe het precies zit met de sites benaderen via ip/~username. Ik wilde dus van chmod 777 af en heb mappen als cache veranderd naar 700, en werkt prima onder domein.tld. Maar voor ip~/username is dit niet voldoende.
Een print exec('whoami'); geeft onder domein.tld netjes de user, maar onder ip/~username apache. Ik ben even gaan kijken naar de configs en het lijkt me ook logisch, aangezien de template vhosts per domein de RUidGid wordt ingesteld. Immers, bij ip/~user wordt er geen domein aangeroepen.
Ik heb overigens in de hoofd httpd.conf RUidGid apache access ingesteld, omdat ik gebruik maak van deze optie http://www.directadmin.com/features.php?id=961 - met apache apache kreeg ik bij ip/~username forbidden.
Klopt mijn redenatie, en is mod_ruid dus niet werkend onder ip/~username?
Yourwebhoster
25/08/10, 16:36
Klopt mijn redenatie, en is mod_ruid dus niet werkend onder ip/~username?
mod_ruid werkt wel maar je kan het niet configureren voor ip/~username. De reden hiervoor is dat je niet voor elke username een aparte config hebt in httpd-userdir.conf, waardoor je de username niet kan instellen voor mod_ruid.
Oke dan is dat duidelijk. :) Jammer, maar er is wel omheen te werken.