# Pravice datotek na spletnem strežniku

> Pravilne pravice datotek na spletnem strežniku: ločeni lastniki, 640 namesto 777, pisanje samo za nalaganja in predpomnilnik. Z ukazi za preverjanje.

Vir: https://phpsos.de/sl/ratgeber/dateirechte-webserver/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Pri pravicah datotek na spletnem strežniku velja eno načelo: uporabnik, pod katerim teče PHP, sme lastno kodo brati, ne pa spreminjati. Pravice pisanja dobijo samo mape za nalaganja, predpomnilnik in tmp, tam pa se PHP ne izvaja. Pravice, kot je 777, na produkcijskem strežniku nimajo kaj iskati.

## Zakaj pravice datotek po vdoru naredijo razliko

Ko napadalci prek ranljivosti izvedejo kodo na strežniku, ta koda teče s pravicami procesa PHP. Kar sme ta uporabnik, sme tudi napadalec. Prav tu se odloči, ali iz vdora nastanejo trajna stranska vrata.

S PHP2Shell je ta scenarij oktobra 2026 postal zelo konkreten. Ranljivosti CVE-2026-109618 in CVE-2026-109619 omogočata izvajanje škodljive kode brez prijave. Odpravljeni sta od 21. 10. 2026 v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Dobre pravice datotek napada ne preprečijo, preprečijo pa, da bi vnesena koda trajno prepisala vašo aplikacijo.

Pri številnih namestitvah vsa koda pripada uporabniku spletnega strežnika, da posodobitve delujejo na pritisk gumba. To je udobno, a prav to je konstelacija, ki jo napadalci iščejo.

## Osnovno načelo: ločite lastnika in uporabnika med izvajanjem

Smiselna je delitev na dve vlogi. Lastnik, na primer uporabnik deploya, je lastnik datotek in namešča posodobitve. Proces PHP teče pod drugim uporabnikom in ima prek skupine samo pravico branja.

| Področje | Lastnik : skupina | Pravice datotek | Pravice map |
|---|---|---|---|
| Programska koda | deploy : seite1 | 640 | 750 |
| Konfiguracija z gesli | deploy : seite1 | 640 | – |
| Nalaganja, predpomnilnik, tmp | seite1 : seite1 | 640 | 750 |
| Dnevniki | root ali seite1 | 640 | 750 |

Sam spletni strežnik, na primer Nginx, pri PHP-FPM potrebuje samo dostop za branje do statičnih datotek, kot so slike in CSS. Dobi ga prek skupine ali ciljnega pravila dostopa. Kdor upravlja več spletnih strani, vsaki dodeli lastnega uporabnika med izvajanjem; kako to sodeluje s pooli, piše v vodniku [open_basedir in izolacija po spletnih straneh](https://phpsos.de/sl/ratgeber/open-basedir/).

## Preverjanje pravic datotek na spletnem strežniku

Preden karkoli spremenite, si ustvarite pregled. Naslednji ukazi nič ne spremenijo.

```bash
# Pod katerim uporabnikom tečejo procesi PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Datoteke in mape, v katere lahko piše vsak
find /var/www -perm -o+w -ls

# Datoteke, ki pripadajo uporabniku spletnega strežnika (primer www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Pravice konfiguracijskih datotek
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
```

Vnosi, v katere lahko piše vsak, so skoraj vedno napaka. Datoteke PHP, ki pripadajo uporabniku med izvajanjem, kažejo, da lahko ta uporabnik spreminja lastno kodo. Sumljive so tudi posamezne datoteke, katerih lastnik ali pravice odstopajo od sosednjih. To je lahko namig na vnesene datoteke, kot je opisano v vodniku [Prepoznavanje in odstranitev webshellov](https://phpsos.de/sl/ratgeber/webshell-erkennen/).

## Popravljanje pravic: korak za korakom

Pravice spreminjajte samo po varnostnem kopiranju in po možnosti najprej v testnem okolju. Če obstaja sum vdora, najprej zavarujte sledi, saj sta lastnik in časovni žig tedaj dokazno gradivo.

```bash
SITE=/var/www/seite1
# Lastnik: uporabnik deploya, skupina: uporabnik med izvajanjem
sudo chown -R deploy:seite1 "$SITE"
# Mape 750, datoteke 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Samo te mape sme PHP pisati (poti prilagodite aplikaciji)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
```

Nato spletno stran preverite v celoti: začetna stran, prijava, obrazci, nalaganje slik, predpomnilniki. Katere mape mora aplikacija pisati, piše v sistemskih zahtevah proizvajalca na njegovi uradni strani.

> **Pomembno:**
> Ukaz `chmod -R 777` za hitro rešitev težave strežnik odpre vsakemu lokalnemu uporabniku in vsakemu vnesenemu procesu. Namesto tega popravite lastnika in skupino.

## Preprečite izvajanje PHP v mapah, v katere je mogoče pisati

Pravice pisanja so le napol tako nevarne, če tam ni mogoče izvajati kode. Izvajanje PHP v mapah za nalaganje in predpomnilnik blokirajte na ravni spletnega strežnika. Za Apache v konfiguraciji VirtualHost:

```apache
<Directory "/var/www/seite1/public/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>
```

Za Nginx zadošča blok `location`, ki zavrne zahteve za datoteke PHP v teh mapah. Pravilo sodi v konfiguracijo strežnika, ne v `.htaccess` v mapi za nalaganje, ki bi jo lahko napadalec s pravicami pisanja znova spremenil.

Dodatno se splača pogledati `umask` uporabnika deploya, da se nove datoteke ne ustvarjajo samodejno preveč odprte. Vrednost `027` vodi do 640 za datoteke in 750 za mape. Na lastnih strežnikih ta odgovornost v celoti leži na vas; kaj sodi zraven še, opisuje stran [Samostojna zaščita root strežnika in vServerja](https://phpsos.de/sl/server/root-server-vserver/).

## Posebni primeri: upravljalni paneli gostovanja, shared hosting in deploymenti

Vsakega strežnika ni mogoče nastaviti po učbeniku. Upravljalni paneli gostovanja, kot sta Plesk ali cPanel, ustvarijo lastne uporabnike in pravice ter jih pri nekaterih dejanjih ponastavijo. Pravice tam po možnosti spreminjajte prek funkcij panela ali po posodobitvah panela preverite, ali vaše nastavitve še veljajo.

Pri shared hostingu imate običajno samo enega uporabnika za vse. Ločitev lastnika in uporabnika med izvajanjem tedaj ni mogoča. Tem pomembnejše so ozke pravice na konfiguracijskih datotekah, nobenih pravic 777 in izklop izvajanja PHP v mapah za nalaganje, kolikor to ponudnik gostovanja dopušča.

Kdor dela s samodejnimi deploymenti, naj pravice nastavi v samem skriptu deploya. Sicer vsaka nova različica znova vzpostavi staro, preveč odprto stanje. Kratko preverjanje ob koncu deploya, na primer z zgornjim ukazom za datoteke, v katere lahko piše vsak, takšne korake nazaj zanesljivo ujame in ga je mogoče brez velikega napora vgraditi v vsak cevovod.

## Kako PHP SOS pomaga konkretno?

- Zajamemo lastnike, pravice in uporabnike med izvajanjem vseh spletnih strani na strežniku.
- Določimo koncept pravic, ki ustreza vaši aplikaciji in vaši poti posodobitev.
- Uvedemo pravice in blokade izvajanja ter nato spletno stran popolnoma preizkusimo.
- Koncept dokumentiramo, da ga deploymenti in posodobitve ne omilijo znova.

Kako je to vključeno v trajno zaščito, opisuje storitev [Utrjevanje strežnikov PHP](https://phpsos.de/sl/leistungen/server-haertung/).


## Pogosta vprašanja

**Ali so pravice 777 kdaj v redu?**  
Na produkcijskem strežniku praktično nikoli. Pri 777 lahko vsak uporabnik sistema ustvarja in spreminja datoteke. Če aplikacija brez 777 ne teče, je običajno napačno nastavljen lastnik, ne pa pravice preozke.

**Zakaj spletni strežnik ne bi smel spreminjati lastnih datotek?**  
Ker vnesena koda teče s pravicami spletnega strežnika. Če sme spletni strežnik pisati datoteke PHP, lahko napadalec manipulira obstoječe skripte ali ustvari nova stranska vrata. Če lastnika in uporabnika med izvajanjem ločite, ostane koda zaščitena pred pisanjem.

**Kako posodobim CMS, če spletni strežnik ne sme pisati?**  
Posodobitve tedaj tečejo prek lastnika, na primer z WP-CLI, Composerjem ali deploymentom, ne prek gumba za posodobitev v zaledju. To je nekoliko bolj zamudno, vendar vnesena koda programskih datotek ne more spreminjati.

**Katere pravice potrebuje konfiguracijska datoteka z geslom podatkovne zbirke?**  
Čim manj: berljiva za uporabnika PHP, za nikogar drugega. Običajni sta 640 z ustrezno skupino ali 400, če je uporabnik PHP sam lastnik.

## Viri

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: varnostna obvestila](https://www.php.net/)