Mappen, bestanden & rechten - 2021 (WordPress)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

In mei 2020 dacht ik de perfecte rechtenstructuur te hebben uitgevonden. Helaas was het net zo perfect als dat het onwerkbaar was. Daarom terug naar de tekentafel.

Voor een volgende keer: WordPress blijkt een standaard-indeling te hebben: https://wordpress.org/support/article/changing-file-permissions/

Problemen met ontwerp 2020

Zie Mappen, bestanden & rechten - 2020 (WordPress)#Waarom dit geen goede aanpak is en hoofdstuk Principes hieronder.

Inventaris

bal5

/var/www: root:root
Bestanden onder /var/www: jeroen:jeroen
Bestanden binnen een site: jeroen:jeroen

Cloudways

master_blub (de eigenaar van het account) is eigenaar van mappen & bestanden
Alle bestanden en mappen zitten in groep www-data
Bestanden die door WordPress zijn aangemaakt (bv. WordFence-logbestanden) hebben eigenaar nakkwwbb en groep www-data.

dvb1

/var/www: jeroen:jeroen
Bestanden binnen een site: jeroen:jeroen

dvb5

/var/www: root:root
Bestanden direct onder /var/www: jeroen:jeroen
Site-bestanden: jeroen:jeroen

WordPress: Changing File Permissions

WordPress' eigen artikel omtrent rechten: https://wordpress.org/support/article/changing-file-permissions.

Regelmatig kom ik links naar deze pagina tegen (oa [https://stackoverflow.com/questions/18352682/correct-file-permissions-for-wordpress). Ik vind dit artikel behoorlijk onleesbaar, omdat het allerlei uiteenlopende casussen dekt, maar onvoldoende toelicht. Wat ik eruit haal:

Er is een verschil in rechten tijdens installatie en operationeel
Upload-proces is eigenaar van bestanden en mappen (dat zou ik zelf zijn)
Groep: www-data
Algemeen: Mappen: 755. Bestanden: 644.

Hardening WordPress

Oftewel: Na installatie moet je instellingen aanpassen. Zie oa.

https://wordpress.org/support/article/changing-file-permissions (maar één kleine paragraaf)
https://wordpress.org/support/article/hardening-wordpress
http://perezbox.com/2014/11/how-hosts-manage-your-website-security

ACL

Regelmatig kom ik ACL tegen als een mogelijke oplossing voor het inrichten van permissies.

Principes

Beheerder & Apache vereisen verschillende rechten

Dit is de essentie: Beheerder & Apache vereisen verschillende rechten:

Beheerder

Bij voorkeur alle bestanden kunnen lezen & schrijven
Geen probleem als er bestanden zijn waar beheerder niet zomaar bijkan, zoals uploads of WordFence-bestanden
Alle mappen moeten in beginsel executeerbaar zijn
Bestanden hoeven nooit executeerbaar te zijn. Enige uitzondering zouden eigen Bash-scripts zijn, die ik soms ergens binnen een installatie parkeer.

Apache

Alle mappen executeerbaar & leesbaar
Alle bestanden leesbaar
(Beperkt) schrijfrechten om zichzelf te kunnen updaten? Bij voorkeur is dit dynamisch. Dus soms tijdelijk verruimd om te kunnen updaten, en verder zo beperkt mogelijk.

Upload-proces is eigenaar

Het proces dat bestanden upload naar de webserver, moet tevens de bedoelde eigenaar zijn van die mappen en bestanden op de doellocatie en bronlocatie. Op het moment dat daar een discrepantie tussen zit, kunnen er complicaties onstaan - Dat was één van de problemen met het vorige ontwerp qua bestandsrechten: Op bronlocatie was Apache eigenaar en beheerder de groep. Na uploaden werd beheerder de eigenaren, waardoor er niet meer in submappen geschreven kon worden - Dat kon Apache immers ook niet in de oude situatie (als eigenaar).

Ik upload middels SSH. Daarbij word ik de eigenaar op de doellocatie. Kijk maar:

$ rsync test.tmp dvb8:
$ dvb8
$ ll

-rw-rw-r-- 1 jeroen jeroen    0 Sep 20 09:56 test.tmp

Maw.: Als ik recht-toe-recht-aan bestanden overfiets via SSH, dan ben ik inderdaad de eigenaar van deze bestanden op de server.

Eén beheerder

Tot op heden ben ik zelf de enige beheerder. Welliswaar is er backup voor mij, maar deslaniettemin ben ik tot op heden de enige actieve beheerder. Iemand anders hoeft dus niet overweg te kunnen met de bestanden of mappen. Mocht dat onverhoopt toch het geval zijn, dan bestaan er prima oplosingen:

Gebruik su. Vooral als het om een tijdelijke situatie gaat
Gebruik chown om beheer over te nemen
Verzin een nieuw rechtensysteem.

Samengevat: Het is qua beheer geen probleem als ik eigenaar ben van alle bestanden en mappen.

WordPress kan zichzelf updaten - Dynamisch

Het leven wordt erg ingewikkeld als WordPress niet meer zichzelf kan updaten. Aan de andere kant: Qua beveiliging vind ik dat bepaald geen goed idee. Daarnaast is het ongewenst dat andere beheerders zomaar updates kunnen uitvoeren. Oplossing: Maak dit dynamisch:

Een script om rechten te verruimen, bv. om de site bij te werken of als een plugin iets wil doen
Een ander script om rechten te beperken en weer terug te brengen naar de gebruikelijke operationele toestand.

Wat WordPress hier zelf over zegt (licht aangepast):

It is best to lock down your file permissions as much as possible and to loosen those restrictions 
on the occasions that you need to allow write access, or to create specific folders with less 
restrictions for the purpose of doing things like uploading files. Here is one possible permission 
scheme.

All files should be owned by your user account, and should be writable by you. Any file that needs 
write access from WordPress should be writable by the web server (→ group permissions)


Root

The root WordPress directory: all files should be writable only by your user account, except 
.htaccess if you want WordPress to automatically generate rewrite rules for you.


/wp-admin/

The WordPress administration area: all files should be writable only by your user account.


/wp-includes/

The bulk of WordPress application logic: all files should be writable only by your user account.


/wp-content/

User-supplied content: intended to be writable by your user account and the web server process.


/wp-content/themes/

Theme files. If you want to use the built-in theme editor, all files need to be writable by the 
web server process. If you do not want to use the built-in theme editor, all files can be writable 
only by your user account.


/wp-content/plugins/

Plugin files: all files should be writable only by your user account.

Other directories that may be present with /wp-content/ should be documented by whichever plugin 
or theme requires them. Permissions may vary.

Apache-rechten regelen via groep www-data

Hiervoor was het al gezegd: Beheerder en Apache behoeven verschillende rechten. Dat kun je regelen door bv. Apache als other te beschouwen. Ik denk echter dat het handiger is als Apache in de group zit voor relevante bestanden en mappen. De standaardgroep daarvoor, is www-data.

BTW: Dit voelt als de eerste echte keuze in dit proces.

Other mag niets

Other mag niets
Ik heb nooit begrepen waarom op webservers Other vaak leestoegang lijkt te hebben.

/var/www - Zelfde als voor sites

Keep it simple: Gebruik dezelfde instellingen voor /var/www als voor de sites daaronder.

Test - Plat HTML-bestand

Deze test betreft een site die veel simpeler in elkaar zit dan een WordPress-site. In het bijzonder: Een WordPress-site maakt zelf bestanden aan en kan eventueel zichzelf updaten. Dat speelt hier niet.

Testsite aan de praat krijgen

Met bestaande eigen script add_domain een domein en.s3 aangemaakt. Op m'n laptop DNS-entry aangemaakt in /etc/hosts zodat ik deze site kan bereiken vanaf m'n laptop
Bestand index.html met tekst Hello, World! aangemaakt binnen dat hosting-account
Domein aangeroepen in browser (http://en.s3). Ik krijg een (voor mij) verfrissend nieuwe foutmelding: Server unable to read htaccess file, denying access to be safe
Rechten aangepast: sudo chgrp www-data /var/www - probleem opgelost.

Rechten verder inrichten

Groep

Alle bestanden en mappen toewijzen aan groep www-data:

chgrp -R www-data /var/www

Mappen

Rechten op mappen configureren (find werkt recursief):

Ik mag lezen, schrijven & executeren (want mappen!)
Groep mag alleen lezen & executeren
Rest mag niets:

find /var/www -type d -exec sudo chmod 750 {} \;

Bestanden

Rechten op bestanden configureren:

Ik mag lezen & schrijven - Niet executeren, want nergens voor nodig
Apache mag alleen lezen
Rest mag niets:

find /var/www -type f -exec sudo chmod 640 {} \;

Test - WordPress-site

Juhu! En nu zien hoe dit werkt voor een complete WordPress-site - Een WooCommerce-site om precies te zijn: Locale ontwikkelsite http://en.s1 wordt externe testsite http://en.s3.

Rechten bronlocatie aanpassen

Op de bronlocatie waren rechten geconfigureerd conform artikel Mappen, bestanden & rechten - 2020 (WordPress). Ik kon dus geen submappen kopiëren. Oplossing: sudo chmod -R u+rw /var/www/en.s1 (werkt instantaan!).

Kopiëren naar server

Kopiëren gaat middels

rsync -r * dvb8:/var/www/en.s3 --info=progress2

Voorbeeld van twee bestanden. Eerst op de bronlocatie (mijn laptop = ontwikkelomgeving):

-rw-rw----  1 www-data jeroen     653 jul 26 15:21 robots.txt
-rw-rw-r--  1 jeroen   jeroen 1024108 sep  3 10:24 tmp.txt

Dezelfde bestanden op de server:

-rw-rw---- 1 jeroen jeroen      653 Sep 20 11:12 robots.txt
-rw-rw-r-- 1 jeroen jeroen  1024108 Sep 20 11:12 tmp.txt

Oftewel:

Alle bestanden en mappen jeroen:jeroen als eigenaar en groep
Bestandskenmerken zijn ongewijzigd.

Bijwerken rechten

Vanaf de wortel van de site:

find . -type d -exec sudo chmod 750 {} \;   # Duurde ca. 3s
find . -type f -exec sudo chmod 640 {} \;   # Duurde ca. 10s
sudo chgrp -R www-data *                    # Instantaan