Dotaz: update souboru v /etc pres php

[six6]

Rad bych nejakym bezpecnym zpusobem editoval soubor v /etc pres vlastni rozhrani v php. Napada me, ze by php vytvorilo s pozadavkem zmeny nejaky soubor a shell script v cronu pod rootem by si kazdou minutu kontroloval existenci tohoto souboru. V pripade, ze by tam byl, tak by si z nej vytahl hodnoty a pozmenil podle toho soubor v /etc. Nebo napada nekoho nejaky zpusob jak na to?

Odpovědi

[rastos]

Keď už dokážeš v PHP vyrobiť súbor, tak nie je jedno, či jeho existenciu kontroluje cron, alebo ten súbor rovno je v /etc ?

[David Karban]

Je tu docela rozdíl,

za předpokladu, že vlastním rozhraním je myšleno webová php aplikace, tak může mít nastaven zápis třeba jen do dočasné složky. Do toho souboru může zapsat uživatel, tedy je nedůvěryhodný.

Odtud to pak vybere cron skript, který běží pod konzolovým php a ten si projde dočasnou složku, zjistí tam nové verze souborů, udělá kontroly (které nemůže ten, kdo zapisuje do souboru z web aplikace ovlivnit). jestli je vše v pořádku a až pak změny aplikuje.

[six6]

Ano, presne tak. Je to webova aplikace. On by v te samotne aplikaci nemel mit nikdo moznost zapsat cokoliv, ale porad to cele bezi pod uzivatelem. Proto bych to rad jeste osetril tim, ze to bude pracovat pres docasnou slozku. Uzivatel tim nebude muset mit pravo zapisovat primo do /etc (protoze tam by mel prece jen pouze root). A jak rikas, pres nejaky kontrolni mechanismus, ale jaky. Napada me jedine vymyslet vlastni algoristmus, ktery by se porovnaval na kazde strane a prip. kazdy den menil.

[David Karban]

Bez znalostí konkrétních souborů, co se mají měnit těžko poradit :).

Ale obecně, nelze věřit tomu co předá webová aplikace (resp. je dobré předpokládat že může předat cokoliv). Takže kontrola by měla zkontrolovat nejen že tam je soubor, ale i jestli ty záznamy v souboru jsou v pořádku, nejsou tam znaky co v tom souboru být nemůžou a podobně.

Příklad: Při editaci /etc/passwd tímto způsobem bych třeba viděl jako minimální kontrolu, že to nezkouší vytvořit nového uživatele s uid 0 (nebo lépe žádného pod 1000) apod. Ještě lépe, ani bych (u vytvoření uživatele například) neumožnil zadávat UID - jen zadat nové uživatelské jméno. Uid, gid, home, vše by dělal až cron skript (který by kontroloval, jestli už uživatel neexistuje, apod). A kontroloval bych pak jestli uživatelské jméno obsahuje jen alfanumerické znaky (resp. jen znaky, které může uživatelské jméno správně obsahovat).

Je to jako příklad pochopitelné? :).

[Jendа]

Netřeba cron, příkaz můžeš spouštět třeba přes sudo rovnou z toho PHP.

[Julus]

Dalsi moznost: Zmeny si zapis do Databaze nebo filu. A z cronu muzes volat primo php script. (#!/usr/bin/php), sam vyuzivam tohoto zpusobu na background synchronizaci. Je to divne reseni, ale funkcni. Je pravda, ze tyhle veci muze resit perl, sh, ale za 1) neovladam tak jak na urovni php 2) potrebuju pri tom objekty a mysql,oracle,ldap pristup

[rADOn]

Dost by pomohlo kdybys napsal co chces vlastne menit. Vetsina aplikaci dnes umi skladat konfiguraci pomoci nejake varianty include direktivy, cili by ti stacilo psat primo konfigurak do nejaky lokace kam mas pristup z php. Nemusel bys vymyslet "pozadavky na zmenu", stacilo by precist co uz tam je, zmenit a (atomicky) zase zapsat. Ve skriptu bys musel osetrit aby se zapisovaly jen povoleny direktivy, ale to musis nejak osetrit vzdycky. Aplikace vytvorenou konfiguraci includuje do hlavniho konfiguraku, otoceni daemona pri zmene konfiguraku zaridi inotify nastroje.

Pokud nevystacis s necim hodne jednoduchym, tak bych se spis poohlednul po nejakem hotovym demonu ktery by prijimal rozkazy po nejakym IPC (xml-rpc, dbus, ICE…) a umel podle nich delat nejaky predem nastaveny akce. Jednodussi verze by byla mit pripraveny hromady skriptu a dobre napsanej konfigurak pro sudo… To co chces je dost nebezpecna vec takze bych se co nejvic drzel hotovych a vyzkousenych nastroju, i kdyz naucit se s nimi delat treba nebude jednodussi nez si neco zbastlit na kolene.

[six6]

Predem diky vsem za rady, posunulo me to zase kousek dal. Konkretne me jde o jedinou vec a to asi u 20 domen (virtualhost) pridavat/mazat subdomeny.

[rADOn]

To je takrka klasickej priklad. AFAIK vetsina distribuci to dela tak jak jsem to popisoval, treba debiani defaultni konfigurak includuje vsechno co najde v /etc/apache2/sites-enabled/, kazdej vhost tam ma svuj soubor (ve skutecnosti symlink ale to uz je jina pohadka). Cili staci obslehnout tu includovaci direktivu a namirit ji na jiny adresar kam ma tvuj proces pravo na zapis.

btw umis delat atomicke zapisy? Kdyz ti z nejakeho duvodu zdechne proces php – coz se muze stat – behem zapisovani, muzes skoncit s necitelnym konfigurakem a apac nenabehne. Coz nepotesi

[Ales]

proto je dobry pouzit 'apache2ctl configtest' pred votocenum apache.

[six6]

nj, ale jestli chapu spravne jak to myslis, tak porad budu mit nekde slozku sites-enabled (prip. sites-available) s pravama r/w, abych to mohl editovat. Sice uz nebude vystavena cela /etc, ale sites-en./av. bude. Porad se me zda, ze nejlepsi reseni bude nejaka tmp slozka s docasnym konf. souborem a do ni si bude sahat skript z cronu uz s root pravama (+nejaky overovaci mechanismus). Atomicky zapis jsem neznal, diky.

[rADOn]

Straslive nebezpecny to bude at uz to udelas jakkoliv. Zvlast jestli to bude konfigurace stejneho apace nad kterym pobezi ten samotny editacni skript. Skript ktery by to zvalidoval nezavisle a neslo by ho zevnitr php ovlivnit by byl samozrejme plus, ale nemusis na nej delat vlastni "zmenovy" minijazyk, stacil by v podstate sed skript ktery by by zkontroloval predlozeny uz hotovy konfigurak. Dalsi co by pomohlo je nesnazit se porozumet a zapisovat z php primo do konfiguraku, ale proste ho serializovat do nejakyho objektu, zmenit co potrebujes a cely zapsat nacisto (coz stejne potrebujes kvuli atomicite). Tim muzes snaz zarucit ze se do toho konfiguraku dostane jen to co tam patri. Nebo muzes drzet a editovat "zdrojovou" konfiguraci nekde bokem v databazi a konfigurak psat pokazde nacisto. Apac ma dokonce moduly ktere umi cist konfiguraci virtualhostu primo z sql databaze…

[Kit]

Apac ma dokonce moduly ktere umi cist konfiguraci virtualhostu primo z sql databaze…

Tohle řešení by mohlo být nejzajímavější. Něco jsem sice našel, ale to asi nebude ono.

[Ales]

pokud subdomeny budou jen subweby, tak nejjednoduzsi je v dns pouzit wildcard *.domena.tld a v httpd pak subdomeny dynamicky generovat adresarovou strukturou a rewrajtama.

v pripade ze subdomena bude na jinym kompu/ipecku/jina sluzba, tak misto bindu pouzit mydns. k tomu se da pak udelat management (na https) jednoduse, zony si uklada do mysql a do ni bude mit prava select a insert. bind se da pouzit jako sekundarni dns.

jestli musis/chces zustat u bindu, tak se daj zony uklada jinam nez do /etc. server neni potreba restartovat, staci vyuzit nastroj rndc, ale to muze jen root. reseni zmeny usera v managementu (na https) but pomoci sudo, apache suexec ci cgi phpkem se nevyhnes. a to ti, kvuli 20 domenam co bude editovat pravdepodobne kolega, za namahu podle me nestoji.

[six6]

dynamicky generovat adresarovou strukturou a rewrajtama .... to je dobrej napad. Kousek jina cesta nez jsem myslel, zvazim ... Dekuju

[Josef Kufner]

Ono ani nemusis nic generovat. Koukni na Dynamic Virtual Hosts. Pak vyrobíš virtualhost prostým vytvořením adresáře.