Mappen, bestanden & rechten - 2021 (WordPress): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 171: Regel 171:
 
</code>
 
</code>
  
Daardoor krijgen alle bestanden en mappen jeroen:jeroen als eigenaar en groep.
+
Voorbeeld van twee bestanden. Eerst op de bronlocatie (mijn laptop = ontwikkelomgeving):
 +
 
 +
<pre>
 +
-r--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
 +
</pre>
 +
 
 +
Dezelfde bestanden op de server:
 +
 
 +
<pre>
 +
-r--rw---- 1 jeroen jeroen      653 Sep 20 11:12 robots.txt
 +
-rw-rw-r-- 1 jeroen jeroen  1024108 Sep 20 11:12 tmp.txt
 +
</pre>
 +
 
 +
Oftewel:
 +
 
 +
* Alle bestanden en mappen jeroen:jeroen als eigenaar en groep
 +
* Bestandskenmerken zijn ongewijzigd.
  
 
== Bronnen ==
 
== Bronnen ==

Versie van 20 sep 2021 09:17

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.

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

WordPres: Chaning File Permissions

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

Regelmatig kom ik links naar deze pagina tegen:

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

ACL

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

Principes

WordPress kan zichzelf updaten

Het leven wordt te ingewikkeld als WordPress niet meer zichzelf kan updaten. Ook al vond ik dat qua beveiliging geen goed idee

Conventioneel

Een ander probleem met de aanpak uit 2020: Het was té afwijkend en dat gaf allerlei complicaties. Daarom graag terug naar iets conventioneels.

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.

Beheerder & Apache vereisen verschillende rechten

Dit is wellicht 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
  • Alle mappen moeten 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
  • Schrijfrechten om zichzelf te kunnen updaten?

Beheerder is eigenaar van bestanden en mappen

Vermoedelijk de gemakkelijkste aanpak: Het proces dat bestanden upload, is tevens de eigenaar van deze bestanden. Anders moet je extra handelingen verrichten om na uploaden rechten aan te passen (dat schijn je trouwens te kunnen automatiseren). In de praktijk ben ik daardoor zelf de eigenaar van bestanden en mappen.

Kleine test:

$ 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 de eigenaar op de server.

Overigens: Als een site eenmaal in productie is, komt het vrijwel nooit voor dat ik nog bestanden uploaden. Dus eigenlijk boeit dit allemaal amper, zolang ik een script of commando heb om de rechten in één keer aan te passen.

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.

Other mag niets

Misschien overdreven, maar ik vind het idee dat er een groep 'other' is, die überhaupt iets mag - Al is het maar lezen - een slecht idee.

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

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

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

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

Bronnen