# Fájljogosultságok a webszerveren

> Fájljogosultságok webszerveren: külön tulajdonosok, 640 a 777 helyett, írási jog csak feltöltéseknek és gyorsítótárnak. Parancsok az ellenőrzéshez.

Forrás: https://phpsos.de/hu/ratgeber/dateirechte-webserver/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A webszerver fájljogosultságainál egy alapelv érvényes: az a felhasználó, amely alatt a PHP fut, olvashatja a saját kódját, de nem módosíthatja. Írási jogot csak a feltöltési, gyorsítótár- és temp-mappák kapnak, és ott nem hajtanak végre PHP-t. A 777-hez hasonló jogoknak nincs helyük egy éles szerveren.

## Miért dönt a fájljogosultság egy behatolás után

Ha a támadók egy résen keresztül kódot futtatnak egy szerveren, ez a kód a PHP-folyamat jogaival fut. Amit ez a felhasználó megtehet, azt megteheti a támadó is. Éppen itt dől el, hogy egy behatolásból tartós hátsó ajtó lesz-e.

A PHP2Shell révén ez a forgatókönyv 2026 októberében nagyon konkréttá vált. A CVE-2026-109618 és CVE-2026-109619 rések bejelentkezés nélküli kártékony kód futtatását teszik lehetővé. 2026. 10. 21. óta javítva vannak a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban. A jó fájljogosultságok nem akadályoznak meg egy támadást, de megakadályozzák, hogy a bejuttatott kód tartósan átírja az alkalmazását.

Sok telepítésben az egész kód a webszerver-felhasználóhoz tartozik, hogy a frissítések egy gombnyomásra működjenek. Ez kényelmes, de éppen az a konstelláció, amelyet a támadók keresnek.

## Az alapelv: a tulajdonos és a futtató felhasználó szétválasztása

Célszerű két szerepre osztani. Egy tulajdonos, például egy deploy-felhasználó birtokolja a fájlokat és telepíti a frissítéseket. A PHP-folyamat egy másik felhasználó alatt fut, és csak a csoporton keresztül van olvasási joga.

| Terület | Tulajdonos : csoport | Fájlok jogai | Mappák jogai |
|---|---|---|---|
| Programkód | deploy : seite1 | 640 | 750 |
| Konfiguráció jelszavakkal | deploy : seite1 | 640 | – |
| Feltöltések, gyorsítótár, temp | seite1 : seite1 | 640 | 750 |
| Naplók | root vagy seite1 | 640 | 750 |

Maga a webszerver, például az Nginx, PHP-FPM mellett csak olvasási hozzáférést igényel a statikus fájlokhoz, például a képekhez és a CSS-hez. Ezt a csoporton vagy egy célzott hozzáférési szabályon keresztül kapja meg. Aki több weboldalt üzemeltet, mindegyiknek saját futtató felhasználót ad; hogyan működik ez együtt a poolokkal, azt az [open_basedir és weboldalankénti elkülönítés](https://phpsos.de/hu/ratgeber/open-basedir/) útmutató írja le.

## Fájljogosultságok ellenőrzése a webszerveren

Mielőtt bármit módosítana, szerezzen áttekintést. A következő parancsok nem változtatnak semmin.

```bash
# Melyik felhasználó alatt futnak a PHP-folyamatok?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Mindenki számára írható fájlok és mappák
find /var/www -perm -o+w -ls

# A webszerver-felhasználóhoz tartozó fájlok (példa: www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# A konfigurációs fájlok jogai
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
```

A mindenki számára írható bejegyzések szinte mindig hibát jelentenek. A futtató felhasználóhoz tartozó PHP-fájlok azt mutatják, hogy ez módosíthatja a saját kódját. Feltűnőek emellett az egyes fájlok, amelyek tulajdonosa vagy jogai eltérnek a szomszédos fájlokétól. Ez bejuttatott fájlokra utalhat, ahogy azt a [Webshellek felismerése és eltávolítása](https://phpsos.de/hu/ratgeber/webshell-erkennen/) útmutató leírja.

## Jogok javítása: lépésről lépésre

A jogokat csak mentés után, lehetőleg előbb egy tesztkörnyezetben módosítsa. Ha behatolás gyanúja áll fenn, előtte mentse a nyomokat, mert a tulajdonos és az időbélyegek ilyenkor bizonyítékok.

```bash
SITE=/var/www/seite1
# Tulajdonos: deploy-felhasználó, csoport: futtató felhasználó
sudo chown -R deploy:seite1 "$SITE"
# Mappák 750, fájlok 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Csak ezeket a mappákat írhatja a PHP (az útvonalakat igazítsa az alkalmazáshoz)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
```

Ezután ellenőrizze a weboldalt teljesen: nyitóoldal, bejelentkezés, űrlapok, képfeltöltés, gyorsítótárak. Hogy mely mappákat kell az alkalmazásnak írnia, azt a gyártó rendszerkövetelményei tartalmazzák a hivatalos oldalán.

> **Fontos:**
> Egy `chmod -R 777`, amellyel gyorsan megold egy problémát, megnyitja a szervert minden helyi felhasználó és minden bejuttatott folyamat előtt. Ehelyett a tulajdonost és a csoportot javítsa.

## A PHP-végrehajtás megakadályozása írható mappákban

Az írási jogok csak félig olyan veszélyesek, ha ott nem futhat kód. Tiltsa le a PHP végrehajtását a feltöltési és gyorsítótár-mappákban a webszerver szintjén. Apache esetén a VirtualHost-konfigurációban:

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

Nginxhez elég egy `location` blokk, amely elutasítja az ezekben a mappákban lévő PHP-fájlokra irányuló kéréseket. A szabály a szerverkonfigurációba tartozik, nem a feltöltési mappában lévő `.htaccess`-be, amelyet egy írási joggal rendelkező támadó ismét megváltoztathatna.

Kiegészítésként érdemes megnézni a deploy-felhasználó `umask` értékét, hogy az új fájlok ne jöjjenek létre automatikusan túl nyitottan. A `027` érték a fájloknál 640-et, a mappáknál 750-et eredményez. Saját szervereken ez a felelősség teljes egészében Önt terheli; hogy mi tartozik még ide, azt a [Root szerver és vServer saját védelme](https://phpsos.de/hu/server/root-server-vserver/) írja le.

## Különleges esetek: tárhelypanelek, megosztott tárhely és deploymentek

Nem minden szerver állítható be tankönyv szerint. Az olyan tárhelypanelek, mint a Plesk vagy a cPanel, saját felhasználókat és jogokat hoznak létre, és egyes műveleteknél visszaállítják őket. A jogokat ott lehetőleg a panel funkcióin keresztül módosítsa, vagy panelfrissítések után ellenőrizze, hogy a beállításai még érvényesek-e.

Megosztott tárhelyen többnyire csak egy felhasználója van mindenre. A tulajdonos és a futtató felhasználó szétválasztása ekkor nem lehetséges. Annál fontosabbak a konfigurációs fájlok szűk jogai, a 777-es jogok mellőzése és a PHP-végrehajtás kikapcsolása a feltöltési mappákban, amennyiben a tárhelyszolgáltató ezt megengedi.

Aki automatikus deploymentekkel dolgozik, a jogokat magában a deployment-szkriptben állítsa be. Különben minden új verzió visszaállítja a régi, túl nyitott állapotot. A deployment végén egy rövid ellenőrzés, például az írható fájlokra vonatkozó fenti paranccsal, megbízhatóan elfogja az ilyen visszalépéseket, és nagy ráfordítás nélkül beépíthető bármely pipeline-ba.

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük a szerver összes weboldalának tulajdonosát, jogait és futtató felhasználóját.
- Meghatározunk egy jogosultsági koncepciót, amely illeszkedik az Ön alkalmazásához és frissítési útjához.
- Bevezetjük a jogokat és a végrehajtási tiltásokat, majd teljesen teszteljük a weboldalt.
- Dokumentáljuk a koncepciót, hogy a deploymentek és a frissítések ne lazítsák meg újra.

Hogyan ágyazódik ez be egy tartós védelembe, azt a [Szerver-keményítés PHP-webszerverekhez](https://phpsos.de/hu/leistungen/server-haertung/) szolgáltatás írja le.


## Gyakori kérdések

**Jó valaha a 777-es jog?**  
Éles szerveren gyakorlatilag soha. A 777-tel a rendszer minden felhasználója létrehozhat és módosíthat fájlokat. Ha egy alkalmazás 777 nélkül nem fut, többnyire a tulajdonos van rosszul beállítva, nem a jog túl szűk.

**Miért ne módosíthassa a webszerver a saját fájljait?**  
Mert a bejuttatott kód a webszerver jogaival fut. Ha a webszerver írhat PHP-fájlokat, a támadó meglévő szkripteket manipulálhat vagy új hátsó ajtókat hozhat létre. Ha a tulajdonost és a futtató felhasználót elválasztja egymástól, a kód írásvédett marad.

**Hogyan frissítsek egy CMS-t, ha a webszerver nem írhat?**  
A frissítések ilyenkor a tulajdonoson keresztül futnak, például WP-CLI-vel, Composerrel vagy deploymenttel, nem az admin felület frissítés gombjával. Ez kicsit körülményesebb, de a bejuttatott kód így nem tud programfájlokat módosítani.

**Milyen jogok kellenek az adatbázisjelszót tartalmazó konfigurációs fájlhoz?**  
Minél kevesebb: olvasható a PHP-felhasználónak, senki másnak. Szokásos a 640 megfelelő csoporttal, vagy a 400, ha a PHP-felhasználó maga a tulajdonos.

## Források

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz (német Szövetségi Információbiztonsági Hivatal)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: biztonsági közlemények](https://www.php.net/)