PeHa ICT

Bij het kopiëren van een website om als basis te dienen van een volgende website, komt het nog wel eens voor dat die nieuwe site niet van dezelfde owner moet zijn als de oorspronkelijke site. Middels het linux commando chown is dat snel te regelen, maar heeft een lastige beperking: het past alle files en mappen aan, ook die van de owner apache zijn, om bijvoorbeeld logs of uploads te verwerken.

mkdir /www/newsite
cp -r -a /www/oldsite/website /www/newsite/

Bovenstaande regels maken eerst middels mkdir een nieuwe map aan om de nieuwe site in te plaatsen. De tweede regel kopieert (cp) de map /www/oldsite/website naar de zojuist aangemaakte directory. Daarbij worden 2 switches gebruikt:

• -r zegt dat we recursief willen werken, dus niet alleen de lege map moet gekopieerd worden, maar ook de inhoud aan files en submappen moet meekomen
• -a  staat voor -dR of --perserve=all. Eigenlijk wordt dus de -r van hiervoor dus ook al meegenomen. Belangrijker vind ik het dat preserver de owner, mode (chmod) en timestamps meeneemt.

Als ik dus als "root" deze map kopieer, dan zijn daarna niet de files ineens van Root, maar nog steeds van "ownerOldSite".

drwxrwx--- 2 owneroldsite apache 4096 Apr 20  2012 cache
drwxr-x--- 2 owneroldsite apache 4096 Feb 27 15:01 cli
drwxr-x--- 2 owneroldsite apache 4096 May 16 10:14 config
drwxr-x--- 9 owneroldsite apache 4096 May 16 10:11 docroot
drwxrwx--- 3 owneroldsite apache 4096 Jul 18  2012 documenten
drwxrwx--- 2 owneroldsite apache 4096 Jun 14  2012 logs
drwxr-x--- 9 owneroldsite apache 4096 May 15 16:14 mvc

Vervolgens wil ik de site niet van deze owner laten zijn, maar van een nieuwe user: ownerNewSite.

useradd ownerNewSite

De volgende stap is om hem de rechten te geven op de zojuist gekopieerde document root. In principe zou

chown -R ownerNewSite /www/oldsite/website 

voldoen. Echter, in de map documenten in in logs staan files die door de webserver (php) bewerkt moeten kunnen worden. Ze zijn veelal ook aangemaakt door php en hebben daarom als owner ook Apache staan. Met de bovenstaande chown actie zouden die files allemaal een nieuwe eigenaar krijgen en daarmee zouden ze niet meer beschrijfbaar zijn voor PHP.

Oplossing

Er moet dus gefilterd worden op de files die als owner nu ownerOldSite hebben. Dat gaat met de volgende regel:

find ./ -user ownerOldSite 

Alternatief, als het numerieke userid bekend is:

find ./ -uid 999

Dit uid is bijvoorbeeld te vinden in /etc/passwd. Bovenstaand commando zoekt vanuit de huidige map: ./

Daarmee hebben we de files te pakken, maar nog niet aangepast. Dat kan middels -exec:

find ./ -user ownerOldSite -exec chown ownerNewSite {} +

Eventueel kan ook de group van de files nog aangepast worden met:

find ./ -group groupOldSite -exec chgrp groupNewSite {} +

Hiermee heb je dan dus een complete document root gekopieerd, de files die schrijfbaar moeten zijn voor Apache zijn van Apache gebleven, en er is een nieuwe user die de site kan beheren.

Waarom?

Het was voor mij een terugkerende ergernis: ik gebruikte het botte chown om de nieuwe owner aan te geven, en moest daarna door de boom met mappen heen om de juiste mappen weer schrijfbaar te maken voor Apache. Hiermee zou dat verleden tijd moeten zijn

Bij dezelfde server als in mijn vorige post, kwam ook het probleem naar voren, dat de firewall vrijwel alle poorten gesloten had: De webserver (poort 80) was niet bereikbaar, ftp werkte niet. En dat alleen "van buiten" want via de localhost waren de services wel te bereiken.

De volgende aanpassingen waren daarom gedaan aan /etc/sysconfig/iptables

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#ftp:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-I INPUT -p tcp -m tcp --sport 20 --dport 1024:65535 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Dit regelt dan de poorten 80 en 443 toegankelijk zijn: voor de websites.

Poort 22 is voor SSH toegang

Poort 21 en 20 hebben betrekking op het opzetten van een FTP-verbinding. Opzetten, want nadat de verbinding is opgezet, wordt de data heen en weer gestuurd over andere poorten: tussen de 1024 en 65535. Dat staat bekend als een Passive connectie. Als je je moet beperken tot poort 20 en 21, dan spreekt met van een Actieve connectie.

Helaas is dat nog niet voldoende. Er moet namelijk ook nog uitgevoerd worden (als root): modprobe ip_conntrack_ftp

Om deze kernel module ook bij het herstarten van iptables actief te houden, dient aan /etc/sysconfig/iptables-config toegevoegd te worden:

IPTABLES_MODULES="ip_conntrack_ftp"

Bij mij stond de regel al in de config file, zij het met een lege string erachter.

Vandaag een heb ik een server ingericht. Het was een kale installatie van CentOS 6.4. Apache erop, PHP erbij en Mysql. De demo pagina werd keurig getoond, maar zodra ik een file uit een andere document root probeerde te halen, bleven de permission denied errors:

Permission denied: access to /index.html denied

maar om mijn oren vliegen. Zoeken en zoeken dus: de document root was leesbaar voor de group Apache, de files ook (chmod 750 op de document root map en 644 op de files daarin.)

Uiteindelijk bleek de fout te liggen bij "selinux". Deze hardnekkige beveiliging heeft me in het verleden vaker parten gespeeld. Een ook toen heb ik gekozen om hem uit te schakelen:

setenforce 0

Weer inschakelen zou kunnen met

setenforce 1

Helaas zou na een reboot Security-Enhanced Linux weer actief zijn, dus het is ook nodig om de file /etc/sysconfig/selinux of /etc/selinux/config aan te passen en te zorgen dat de regel

SELINUX=disabled

aanwezig is