Onderwerp: Patch voor +FollowSymlinks, al iemand met mod_ruid2 getest?

Zoals hier te zien is:
http://www.directadmin.com/forum/sho...681#post214681
heeft DA de patch van StevenC/Rack911 in een custombuild update mogelijkheid gebouwd.

Dit gaan er dan straks standaard in.

Zijn er nog dingen hierbij om aan te denken als je mod_ruid2 geinstalleerd hebt? Of anders gewoon voor de zekerheid even mod_ruid2 opnieuw erop zetten?

Verder vraag ik me af of SymLinksIfOwnerMatch hetgeen dan de enigeoptie wordt, hetzelfde kan als FollowSymlinks.
Als je bijv. naar Zen Cart kijkt dan kun je dit tegen komen.

## the following line is needed to allow Download-By-Redirect to work
Options +FollowSymLinks

Werkt die Download-by Redirect ook met die vervanger?

Ik heb recent een nieuwe server geinstalleerd met een verse DA-install waar ik de data van klanten van een andere server naar gekopieerd heb (backup/restore) en aan het aftesten ben alvorens live te gaan. De meeste sites gaan prima, maar bij een aantal grote problemen door deze 'patch' van DA. Van de 553 accounts zijn er zo'n 15 stuks die mis gaan.

Gebruikers hebben bijvoorbeeld in hun .htaccess

Options +FollowSymLinks

Voor ik de patch uitvoerde wilden deze websites niet (meer) draaien en kreeg ik de volgende foutmeldingen in de error log:

/home/gebruikersnaam/public_html/.htaccess: Option FollowSymLinks not allowed here

Na de fix:

/home/gebruikersnaam/public_html/.htaccess: Options not allowed here

Op het DA-forum gezien dat sommigen dan custom httpd bestanden gaat aanmaken (AllowOverride All invoegen), maar dat lost het probleem niet op. Van één van de goeroes op dat forum las ik dat hij het probleem naar de gebruikers verschuift onder het motto "dat werkt niet meer, los het maar op" maar zo ga ik niet met m'n klanten om.

Ik heb contact met één van de contributers van Custombuild, en hoop dat hij weet hoe dit opgelost kan worden maar wat mij betreft is deze patch dus niet oke. Ben blij dat ik dit niet op een productiemachine heb, ...

-----

Dat als reactie maar ook als vraag eigenlijk, afgeleid hiervan: heeft iemand anders dit ook meegemaakt en eventueel een oplossing er voor? Want kennelijk is het nu dus al 'default' in DA opgenomen (slechte zaak!) met als gevolg dat sites niet meer werken.

Perl scriptje maken dat Options +FollowSymLinks weg haalt uit alle .htaccess bestanden?

Klopt, ik heb het na een test op een testmachine dus wel op een aantal productieservers gedaan en geen problemen gehad.
In de thread bij DA die over deze patch gaat, staat ook een scriptje wat er voor zorgt dat alle +FollowSymlinks vervangt door SymLinksIfOwnerMatch in de .htaccess bestanden.
Vooralsnog ben ik er geen problemen mee tegen gekomen.

Als je 'm weghaalt werken sommige sites niet meer, als je 'm vervangt door SymLinksIfOwnerMatch
Dan krijg je dus deze error bij sommige sites (zoals ik eerder ook aangaf):

/home/gebruikersnaam/public_html/.htaccess: Options not allowed here

Ik heb een aantal sites die compleet niet meer werken. Gelukkig (nog) geen productieserver... had 'm wel graag vandaag online gebracht, maar helaas. Het gebeurt vooral bij websites die ofwel geheel custom gebouwd zijn door klanten ofwel (in sommige gevallen) door/met Installatron geïnstalleerd zijn.

DA had deze 'patch' niet moeten doen, want het is gewoon standaard Apache gedrag waar ze nu op ingrijpen, mijns inziens.

Je kan het eventueel aanpassen maar ik zou het zo laten staan.

File: /etc/httpd/conf/extra/httpd-directories.conf

Code:

<Directory /home>
        AllowOverride all
        #AllowOverride AuthConfig FileInfo Indexes Limit Options=Includes,IncludesNOEXEC,Indexes,ExecCGI,MultiViews,SymLinksIfOwnerMatch,None
        Options IncludesNoExec Includes SymLinksIfOwnerMatch ExecCGI

        <Limit GET POST OPTIONS PROPFIND>
                Order allow,deny
                Allow from all
        </Limit>
        <LimitExcept GET POST OPTIONS PROPFIND>
                Order deny,allow
                Deny from all
        </LimitExcept>
</Directory>

Als er komt te staan Options not allowed here, denk ik dat de optie in de apache conf geblokkeerd wordt, ik heb er geen last van.

Controleer dit eens in je /etc/httpd/conf/extra/httpd-directories.conf daar zou nu onderaan dit moeten staan:

<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit Indexes
Options -MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>

Als dat wat ik vet heb gemaakt nog steeds op Followsymlinks staat, is de foutmelding die jij nog krijgt te verwachten.

DA had deze 'patch' niet moeten doen, want het is gewoon standaard Apache gedrag waar ze nu op ingrijpen, mijns inziens.

Dat zie ik anders, het is toch een beveiligingsprobleem wat gefixed wordt.
En als je er geen gebruik van wilt maken kun je het bij mijn weten gewoon in de options.conf uitzetten.

Edit: Ah, net tegelijk aan het schrijven geweest met Dennis zie ik.

Hier geen enkele problemen ondervonden met de patch. Heb je secure_htaccess toevallig op yes staan/gezet? Als je deze post bekijkt is dat niet nodig wat betreft de veiligheid.

This will allow the secure_htaccess option to be set to "no" (old httpd config setup), but still solve the linking issue with regards to security.

Once testing is under the belt for this patch, we'll set secure_htaccess=no as the default, and harden-symlinks-patch=yes as the default.

Heb hier alleen wat rechten van wat symlinks aan moeten passen omdat die niet meer werkten na de patch. +FollowSymLinks etc in htaccess geen probleem.

@Blacky - helaas, het staat er idd netjes in. Heb van pure ergernis de installatie overnieuw gedaan, nogmaals alles netjes bij gewerkt en hop,... weer hetzelfde probleem. Standaard install is, voorzover ik het nu begrijp, inclusief deze 'patch'.

@Arieh - ben ik niet met je eens, als dit een issue is (en ja, dat is het wel tot op zekere hoogte) dan moet dat door Apache aangepakt worden en niet 'gepached' in het CP. Maar da's een wellus-nietus discussie vrees ik

Ik wacht nog op de reactie van de custombuild contributer. Hij liet me al even kort weten dat het snel te fixen is. Dus,... ben benieuwd (en als dat zo is zal ik de fix hier ook plaatsen).

Als je het snel wilt fixen staat toch in mijn post hierboven? Of lukt het daar ook niet mee?

dan moet dat door Apache aangepakt worden en niet 'gepached' in het CP.

Dat ben ik wel met je eens. Ik weet niet of dat al v.w.b. Apache zelf al gebeurt is, maar voor Cpanel heb je precies hetzelfde al.
Daar kun je deze optie ook gewoon uit of aanzetten via het controlepaneel net zoals in DA bij de options.conf.

Als apache niet snel genoeg is met beveiligen zul je voor je klanten, ook als controlepaneel, iets moeten doen. De beste oplossing is dan een fix te maken waarvan de gebruiker zelf kan kiezen of hij hem wenst te gebruiken of niet.
Omdat niet gebruiken onveilig is, is het standaard activeren van de patch een logische keuze.

Oorspronkelijk geplaatst door dennis0162

Als je het snel wilt fixen staat toch in mijn post hierboven? Of lukt het daar ook niet mee?

Nee, helaas...
Probleem blijft bestaan.

Foutmelding in de errorlog blijft

/home/gebruiker/public_html/.htaccess: Options not allowed here

Oorspronkelijk geplaatst door Blacky

Omdat niet gebruiken onveilig is, is het standaard activeren van de patch een logische keuze.

Nou,... niet als VPS-gebruikers denken "heeeee een update", het installeren en vervolgens vinden dat jij de ellende die er uit voortvloeit mag gaan oplossen - gelukkig liep ik er zelf eerst tegenaan op een machine die nog niet productie draait.

Nou,... niet als VPS-gebruikers denken "heeeee een update"

Dat is dan ook niet het geval. Bij nieuwe installatie staat het standaard aan. Bij bestaande installaties gaat het niet aangepast worden.
Bij een reeds bestaande productiemachine die wel geupdate is staat wel de optie erbij maar niet actief:

harden-symlinks-patch=no

In mijn geval symlinkt httpd-directories.conf -> httpd-directories-old.conf.
Als ik in httpd-directories-old.conf op de betreffende server dit aanpas:

Code:

<Directory /home/*/public_html>
#       AllowOverride FileInfo AuthConfig Limit Indexes
        AllowOverride All
        Options -MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
        <Limit GET POST OPTIONS>
                Order allow,deny
                Allow from all
        </Limit>
        <LimitExcept GET POST OPTIONS>
                Order deny,allow
                Deny from all
        </LimitExcept>
</Directory>

Oftewel de "AllowOverride FileInfo AuthConfig Limit Indexes" weghaal en "AllowOverride All" gebruik. Maar volgens mij ben je dan weer terug bij af... Dit is het enige dat, na veel experimenteren, zoeken en lezen op het DA-forum, werkt. Op deze specifieke, vers geïnstalleerde, server.

Ik geloof dat ik niet echt blij wordt van deze situatie.

@Dennis0162 - jouw oplossing was dus heel dicht bij de waarheid Je hebt me uiteindelijk wel op het spoor gezet hiervoor.

Conclusie - nav de originele post van TS: het is kennelijk toch niet een patch die je zomaar moet uitvoeren en ook is de nieuwste DA-versie (die default dit heeft aanstaan) wat mij betreft een problematische release.