Milyen jogokat a PHP fájloknak

Üdv!

A szakdolgozatom keretén belül írnom kellett egy MySQL, PHP, JS alapú oldalt. Most az lenne a kérdésem, hogy ha én például ezeket a fájlokat (az egész könyvtárat .css-el, .js-el, .php-val) kiíírom egy CD-re (mivel így kell mellékelni) akkor mikor majd használatbavételkor felmásolják ezt a szerver gépre, ami mondjuk egy valamilyen linux egy apache-al akkor milyen jogok lesznek a fájlokon és ki lesz a tulajdonosa? Vagy ha mondjuk egy NTFS-es fájlrendszerről másoljuk be a www mappába ezeket a fájlokat, akkor ki lesz a tulaj és milyen jogok lesznek rajta? Egyáltalán ezeknek a fájloknak milyen jogot kell adni? Nincs semmilyen htaccess fájl meg semmi, a beléptető rendszert én magam írtam meg session kezeléssel, mysql adatbázisban tárolva az egyes session-öket. Azokat a php fájlokat amiket nem szabad kívülről direktbe elérniük a defined ( '_EXEC' ) or die ( '403.14 - Belepes megtagadva.' ); sorral kezdtem, illetve tettem minden mappába egy üres index.html-t ha valamilyen módon tudnának tallózni akkor se kapjanak semmit. Ez valójában a joomla-tól jött de szerintem ezek nem rossz óvintézkedések. Emellett a programban van egy fájl amiből olvasunk és amibe írunk erre 777 jogot adtam, ez a fájl csak arra szolgál, hogy sql lekéréseket hordozzak és tartsak meg, erre a SESSION azért nem volt alkalmas mert azt a carbage colletor kinyírja félóra tétlenség után.

Szóval a kérdésem összefoglalva milyen jogokat kell adni a www alatt lévő fájloknak, ki legyen a tulaj és ha van a php-n keresztül fájlba írás és abból olvasás annak a fájlnak milyen jogai legyenek. Illetve az attributumok, elfelejtődnek e másoláskor, vagy nem? (esetleg még olyat tudok elképzelni, hogy aki mondjuk fel mountolta az adott eszközt annak a tulajdonába lesz a másolt fájl).

Végül is a biztonságot elvileg a beléptető rendszerrel és a fentebb említett két óvintézkedéssel megoldottam és amúgy sem hiszem, hogy ezt a rendszert bárki is törni akarja majd, mert nem olyan környezetben lesz használva. Ezek után mit ajánlotok?

Hozzászólások

na majd jól lesavaznak engem, de érdemes külön usert csinálni, aki az apache-ot futtatja és az ő tulajdonába adni a stuffot, mivel még publikusan nem csináltam, lokálban én chmod u=rwx,g=rw,o=r jogokat szoktam rátenni (természetesen pl. config fájlokra csak a tulaj kap olvasási jogot). Ha CD-ről másolod fel, akkor ha minden igaz, annak a felhasználónak a tulajdonába kerül, aki a cp parancsot kiadja, a default jogok meg általában a /etc/profile umask nevű változójában tárolódnak.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

A webszerver (php-t) futtató felhasználó legyen a tulajdonos r(w)((x)) joggal (pl www-data). Ha nem elég akkor még adni kell neki.

Szia,

Tapasztalatom szerint az apache www-data user-rel fut, ami benne van a www-data group-ban.

Én úgy csinálom, hogy alapesetben a könyvtárak 750 root:www-data, ha a script valamiért ír ebbe a könyvtárba akkor 770 root:www-data. (Valami export-ot tol ide, nem én írtam, de nem akarom piszkálni ezt a script-et - elegánsabb lenne egy tmp subdir és csak arra írásjog).
Minden file 640 root:www-data

"Normális rendszeren nem www-data futtatja az apache-ot?"

De.

"Akkor mi lehet egyáltalán megoldás arra, hogy ha ezt be akarják majd valaha is üzemelni, a jogok megfelelőek legyenek?"

2 verzió van
1. az előbb említett tar (-p)
2. install script, ami root-ként fut, felmásol mindent és beállítja a jogokat.

szerk.: Illetve a fentiek kombinációja, vagy kézzel is be lehet állítani

Jó pár normális rendszeren nem www-data futtat. A tar-os hordozással is az a gond, hogy az uid-et viszi, azaz ha a www-data más uid a célrendszeren, akkor érdekes lesz az eredmény. Ennyit a normális rendszerekről.

Vannak még a normálisan hordozható dolgok, ahol az ilyen attribútumokat, mint például a tulajdonos és group, egy install script állítja be, így mindegy a célrendszeren milyen uid szerepel a megflelő file-ban, sőt, az is mindegy, hogy www-data vagy webmachinator a user....mert installkor jól megadod és kész.

Emellett a programban van egy fájl amiből olvasunk és amibe írunk erre 777 jogot adtam, ez a fájl csak arra szolgál, hogy sql lekéréseket hordozzak és tartsak meg

OMG WTF

A kérdés jogos... :)

"amúgy sem hiszem, hogy ezt a rendszert bárki is törni akarja majd, mert nem olyan környezetben lesz használva"

Az SQL injection-okra se figyeltem oda, mert van ahol az enduser saját SQL utasítást gépelhet be, innentől kezdve nem hiszem hogy azzal fog fáradozni, hogy bejusson a szerverre és a fájl tartalmát írja át... :) Illetve nem hiszem, hogy a TO-n világuralomra törő hackerek dolgoznak. :D A szerverhez is csak rendszergazdák férhetnek hozzá, bár az még felvet egy kérdést, ha az adott szerverhez hozzáfér egy mezei user is és az is tudja szerkeszteni a fájlt az nem a legszerencsésebb, de erre esetleg megoldást nyújthat xclusiv tanácsa. A 770 root:www-data formációra gondolok.

ui: Tényleg nem jutott jobb eszembe az SQL parancs hordozására.

Van egy formom, ami egy szűrőként működik, beállíthatjuk mire szűrünk, majd ezt egy POST-ba elküldjük egy results.php nak. A results.php úgy kezdődik, hogy a kapott POST-ot ami a form kitöltése után egy SQL query-vé áll össze lementi egy fájlba ezután van egy Extjs script ami többek között csinál egy getStudents.php hívást és kilistázza azt egy grid-be. A getStudents hívásnak viszont a szűrés alapján kell megtörténnie. Tudom, lehetett volna más módszerrel is csinálni ezt az egészet, nekem így sikerült megoldani. A gyakorlatban ez így néz ki:

Részlet a results.php-ból:
<?php
$listFile = "js/extjs/listCommand";
$fh = fopen($listFile, 'w') or die("can't open file");
empty($_POST['listCommand']) ? $stringData="nk like '%'" : $stringData = stripslashes ( $_POST['listCommand'] );
fwrite($fh, $stringData);
fclose($fh);
?>

Ez a list.php-ból kapott string, ha üreset kap minden hallgatót kilistáz.

Részlet a results.js-ból:
var store = new Ext.data.JsonStore({
totalProperty: 'total',
root: 'results',
url: 'js/extjs/extjsPHP/getStudents.php',
remoteSort: true,
fields: [
{name: 'students_id'},
{name: 'nk'},
{name: 'name'},
{name: 'state'},
{name: 'state_date'},
{name: 'depart'},
{name: 'tform'},
{name: 'title'},
{name: 'leader1'},
{name: 'leader2'},
{name: 'email'},
{name: 'phone'},
{name: 'comment'}
]
});
store.setDefaultSort('name', 'ASC');

Ezt nem kell kommentálnom.

Részlet a getStudents.php-ból:
$listFile = "../listCommand";
$fh = fopen ( $listFile, 'r' );
$stringData = fread ( $fh, filesize ( $listFile ) );
fclose ( $fh );
$listCommand = $stringData;

"Ez a rendszer most így működik és kb senkit nem érdekel, hogy hogyan és miért, csak engem. Valószínűleg ha újra neki kezdenék a rendszer megírásának sok minden másképpen csinálnék, de most már nem áll módomban változtatni ezen, úgyhogy szerintem hagyom így. Beállítottam neki a 777 root:www-data jogot, majd a dolgozatba is azt írom, hogy ennek az egy fájlnak ezt a jogot állítsák be, a többinek meg ahogyan fentebb leírtad." -> Ez aztan hozza allas. Ezek utan ki akkar neked segiteni szerinted? De olyan kerdeseket tetel fel ami mar a neten megszerezheto. Jah igen angolul. Ha ilyen programkodot adnal be a tanarod helyeben tuti meghuznalak. De a magyar egyetemeken kb ez a szint. Ki jonnek a friss egyetemistak es ok mar mindenhez ertenek vagy inkabb semmihez.
--
1 leszel vagy 0 élő vagy hulla!

Akár milyen hihetetlennek tűnik számodra sokat foglalkoztam a témával és sokat is szenvedtem vele, ettől függ...

Minek kéne nekem megmagyarázni ezt az egészet, valószínűleg unatkoztál nem volt jobb dolgod és szerettél volna valakibe belekötni. Igen nem érdekel senkit a munkám csak engem, ez nagyon elkeserítő de így van. Ezek után elgondolkozik az ember, hogy megéri-e vele annyit szenvedni amennyit. Lehet itt dobálózni az igényességgel és miegymással nem érdekel... Szerintem semmi baj nincs a programkódommal azt leszámítva, hogy nem adatbázisba tárolom a query-t hanem fájlba, de leírtam azt is hogy nincs időm újra írni és szerintem ez a megoldás sem rossz.

Nem mondtam egy szóval sem, hogy mindenhez értek és anélkül hogy akárki is figyelmeztetne arra, hogy mennyit ér a diplomám tisztában vagyok vele. Úgyhogy maradjunk annyiban, hogy szerencsére nem te vagy a tanárom és szerencsére a helyesírási hibákat sem te javítod a dolgozatomban... ;)

Maradjunk annyiban, hogy mindenki kovet el hibakat es pont. De. Ha te nem latod, hogy van hiba a kododban, az mocskos nagy gaz. Ez igy kurvara insecure. Nem csinalunk olyat, hogy "ja, mert nem hasznalja senki"; "nem fer hozza senki" blabla. Te olyan rendszert irsz, amiben diakok adatait tarolod, es nem biztonsagos? Nem baszogatas, probalom kulturaltan leirni, hogy a szemlelettel es a hozaallassal. _mindig_ _mindenre_ figyelni _kell_. Ezernyi doksit lehet talalni a neten, ami kulonbozo webes nyelveket vizsgal meg biztonsagi szempontbol, erdemes lenne atolvasni parat...

Természetesen semmi baj nincs azzal, ha valaki rámutat a hibáimra. Sőt inkább csak örülök neki, mert ezáltal csak jobbá tehetem a kódomat. Megint más az mikor valaki vagdalkozik ész nélkül és csak fikázza a másikat, emellett semmilyen építő kritikát nem tesz hozzá.

De most akkor konkretizáljuk a problémát. Az a bajod/többiek baja, hogy a fájl szerkeszthető és ezáltal olyan parancsokat is le tudnak futtatni, amit nem lenne szabad? Vagy az a baj, hogy az SQL utasításokat kézzel is lehet szerkeszteni?

Ha az adott fájl a root tulajdonába és a www-data grouphoz tartozik, akkor csak a root tudja ezt a fájlt írni, olvasni, módosítani illetve az aki a www-data grouphoz tartozik. Szerintem ezzel kiküszöböltük azt, hogy bárki belepiszkálhasson a fájlba, ha valakinek root jogosultsága van szerveren az előbb fog hozzáférni direktbe a mysql szerverhez mint ehhez a fájlhoz. [FIXME]

A felhasználónak meg muszáj kicsit belenyúlnia a parancsba, ezt lentebb leírtam, hogy miért.

Egyáltalán nem kötekedni akarok csak most nem látom hol a probléma és várom, hogy rá világítsatok... Semmi nagyképűsködés és fennhéjázás nincs a dologban.

Eljuttotunk oda ,hogy ha nincs pl open_basedir szabadon azt csinalok php szarjaidal amit akkarok. Plusz olyan SQL utasitasitasokat adok amilyet akkarok. De legyen valamien setuid emeles a rendszerbe es ugrott dolog. Pusztan 15 masodperc alatt lehet a munakatad roma torni.
--
1 leszel vagy 0 élő vagy hulla!

A szervert, nem én fogom üzemeltetni következésképpen az apache és a php konfigurációjába nem nagyon van lehetőségem belepiszkálni, esetleg a szakdolgozatomban utalhatok arra, hogy milyen opciókat érdemes beállítani az adott szerveren. Az én elgondolásom szerint, ez a weboldal fel fog kerülni, valamilyen egyetemi szerverre amin fut még egy jó pár másik weboldal és az apache már be lesz konfigurálva. Ezt nem tudom, mert nem kötötték az orromra, de ha így van akkor akármennyire is hulladéknak tartod a felsőoktatási intézményeket nem hiszem, hogy a rendszergazdák nem konfigurálták volna fel megfelelően a szervereket.

Programozási oldalról, amit lehet szerintem én azt megtettem, (EXEC, index.html minden mappába) de ha van ötleted és úgy érzed értelmesen le tudod írni ne tartsd vissza. Az sql injectionra még mindig csak azt tudom mondani, hogy aki hozzáfér az oldalhoz, az futtathat sql parancsot, nyilván más nem.

"Ha az adott fájl a root tulajdonába és a www-data grouphoz tartozik, akkor csak a root tudja ezt a fájlt írni, olvasni, módosítani illetve az aki a www-data grouphoz tartozik."

Nem, nem azt jelenti.

Az tudja írni, akinek van rá írási joga.

Van 3 kategória: tulaj, csoport, mindenki.
Bárki tudja írni, ha ilyenek a jogosultságai:
-???????w?

Akkor igaz amit írtál, a file-ra nincs mindenkinek írási joga, csak a tulajnak és/vagy a csoportnak.

Néhány szervert a "dicsőségért" törnek fel (NASA, FBI, Pentagon, ...), néhányat az ott tárolt adatokért, és néhányat politikai okokból. A többséget pedig csak azért, mert meg tudják tenni. Az utóbbiak között sok olyan van, amire a rendszergazda(?) azt mondta: Ezt biztosan nem akarja senki sem feltörni.

-----
"Ha javulni látod a dolgokat, akkor valami fölött elsiklottál."

Tényleg nem kötekedni akarok, de ha elolvastad figyelmesen a thread-ben lévő problémát, akkor az a listCommand nevű fájl hozzáférésével kapcsolatos. Volt rá egy megoldás amivel csak a root és a www-data group-hoz tartozó userek férnek hozzá, innentől kezdve a probléma értelmét vesztette mert ha mezei user nem tartozik a www-data-hoz és nincs root jogosultsága akkor a fájlhoz sem fér hozzá.

Bár gondolom amit te írtál azt általánosságba írtad az adott problémától függetlenül.

"Tényleg nem jutott jobb eszembe az SQL parancs hordozására."

Pedig az nem az igazi.
Extjs-hez nem értek, de ha sehogy nem lehet kultúráltan megcsinálni, akkor csinálnék egy táblát hozzá, 3 field: sessionID, query (text), meg valami mező (timestamp vagy int vagy bármi) amivel jelölöm, hogy a feldolgozó progi méltóztatott-e már végrehajtani.

Ilyenkor elvileg úgy müxik, hogy alapesetben nincs adott sessionhöz tartozó szűz rekord, a hívó kód beírja szűzként, meghívja a kiolvasót az meg kiolvassa az adott session-höz tartozó szűz rekordot és egyúttal át is billenti a nemszűz flag-et.

Aztán ezzel a file-os kommunikációt is kinyírtuk, lehet minden 750/640 root:www-data

Köszönöm az ötletet és tényleg így sokkal jobb lenne, csak az a probléma, hogy november 19. le kell adnom a dolgozatot. Ez a rendszer most így működik és kb senkit nem érdekel, hogy hogyan és miért, csak engem. Valószínűleg ha újra neki kezdenék a rendszer megírásának sok minden másképpen csinálnék, de most már nem áll módomban változtatni ezen, úgyhogy szerintem hagyom így. Beállítottam neki a 777 root:www-data jogot, majd a dolgozatba is azt írom, hogy ennek az egy fájlnak ezt a jogot állítsák be, a többinek meg ahogyan fentebb leírtad.

Most viszont elgondolkoztam valamin és nem értem, hogy miért azt kaptam amit. Van ugyebár a felületem ahová több felhasználó is beléphet, a következő jutott eszembe van a listCommand fájlom amivel az sql stringet hordozom ha belépek mondjuk usera néven és végrehajtok egy szelekciót, például kiszűröm a Gazdinfósokat és csak őket jelenítem meg a listCommand fájl tartalma ez lesz: depart like 'GI' a depart az oszlop neve amire szűrök, megkapom a szűrés eredményét egy táblázatot és örülök. Namost elvileg ha bejelentkezek userb-vel és csinálok egy újabb listázást mondjuk azokat akarom akiknek a Neptnu kódja B-vel kezdődik a listCommand fájl tartalma megint változni fog erre: nk like 'B%' és kapok egy táblázatot ennek alapján. Ezek után arra számítottam, hogyha visszamegyek a usera ablakára és frissítek akkor a listCommand-ból kiolvasva a query-t itt is az összes B-vel kezdődő Neptun kódu emberke fog megjelenni, de nem ez történt ugyanúgy maradtak a GI-sek. Na ezt most nagyon nem értem, hogy miért így történt... :D Ennek örülök de nem ezt vártam. Több felhasználó egy fájl ez elvileg problémát kellene hogy okozzon....

szerk: Megnéztem firebuggal és hiába változik meg a fájl tartalma, ha egy másik ablakban új szűrést csinálok userb-vel, mikor a usera alól újratöltöm az oldalt, ő nem látja a változást. Miért?

Ilyet nem csinalunk, normalis helyen ezert elkaszalnak ugy hogy a szakdoga tobbi reszet meg sem nezik. Mire kell ez?

Ha nagyon valtozo parameterekkel akarsz lekerdezeseket futtatni, tarold el a parametereket az adatbazisban, es abbol ellenorzes utan ossze tudod rakni a lekerdezeseket. Azt nem nyirja ki a session kezeles sem.

Az a baj, hogy amíg nincs előtted a felület addig, nem fogom tudni elmagyarázni, vagy csak nagyon nehezen hogy miért kell ez nekem.
De megpróbálom illusztrálni, tehát itt a felület ahol beállítod mire szűrsz:
http://jani.uw.hu/list.png - Van a betölt gomb, ezután a beállított tulajdonságok egy textarea-ba töltődnek, ahol kézzel is lehet szerkeszteni, mivel a témavezetőnek az volt a kérése, hogy több dologra is lehessen szűrni és annyi kombináció a világon nincs amennyit össze lehet állítani, gondolok itt az AND/OR összekötésekre, ezért én ezt találtam a legjobb megoldásnak, ezután ez a string hozzáfűződik a SELECT többi részéhez és így fut le és adja vissza az eredményt: http://jani.uw.hu/results.png

Most már megértheted, miért nincs arra lehetőség, hogy részenkét állítsam össze a lekérdezést, mivel a lekérdezést kézzel is szerkeszthetjük.

szerk: Csináltam egy folyamat ábrát: http://jani.uw.hu/folyamat_abra.png

Világos, én is a lehető legegyszerűbbre akartam tervezni a felületet, hogy ilyen "összekattintgatós" legyen az egész szinte. De a témavezetőm azt mondta, hogy tőle szoktak ilyen adatokat kérni, hogy például adja már meg azokat a hallgatókat akik PTI-sek vagy MI-sek és 2010-ben adták le a szakdogájukat. Másik példa add meg azokat a hallgatókat akinek vagy az egyes vagy a kettes témavezetőjük Php Pista. Ezek szerintem reális elvárások lehetnek a szűrésnél, szóval lehet vertikálisan és horizontálisan is kapcsolat az adattagok között ráadásul nem mindegy, hogy egyszerre kell teljesülniük vagy csak az egyiknek csak a másiknak stb...

ui: A vertikális/horizontális dolgot úgy értem, hogy monjuk név és Neptun-kód között meg mondjuk név és név között.

Ertem, hat en akkor inkabb ugy csinalnam a dolgokat hogy van egy + gomb amire kattantva megjelenne egy uj felteteli mezo, valaszthato es/vagy kapcsolat, a mezo neve es az ertek hogy mire kell keresni. Ezt annyira nem is maceras leprogramozni sem, viszont az SQL-be semmikepp nem hagynek senkit kezzel beleturkaszni :)

Vagy esetleg minden mezohoz ket vagy harom megadhato ertek koztuk vagy kapcsolattal, es a mezok kozott es kapcsolattal.

Én is gondoltam már erre, most majd még egyszer átgondolom... :) Minden esetre köszi szépen a segítséget.
Arra nincs valami ötleted amit fentebb írtam? Konkrétan, hogy ha két vagy több user-el vagyok bejelentkezve, akkor hogy megy ez a fájl kezelés olvasás/írás, fentebb leírtam részletesen és még mindig nem értem. Valahogy nem olvassa újra a fájl-t vagy nem érzékeli a változtatást...

Elolvastam, de erre eleg nehez igy hozzaszolni. Nekem az a tippem hogy az eredmenyedet becache-eli a bongeszo, es nem tolti ujra de ennek utana kene hogy menj jobban. Vagy esetleg ugy adod at a lekerdezest hogy frissul akkor amikor ujratoltod az oldalt? Ezt a kod ismerete nelkul nehez megmondani.
Ha nem csinaltal semmit hogy elkulonitsd az usereket az mindenkeppen baj, nem szabad hogy egymast befolyasoljak :)

Nincs többé fájl... :)
Az új megoldás, az lett végül amit mondtatok, de mivel már a beléptetés miatt volt nekem egy user-hez kötődő táblám ezért hozzá biggyesztettem egy query oszlopot. Most így néz ki a dolog:

mysql> desc manage_session;


+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| sess_id   | varchar(32) | NO   | PRI | NULL    |       |
| user_id   | int(11)     | NO   | UNI | 0       |       |
| lastlogin | datetime    | YES  |     | NULL    |       |
| query     | text        | NO   |     | NULL    |       |
+-----------+-------------+------+-----+---------+-------+

$default_val = "nk like \'%\'";
$replace = "REPLACE INTO manage_session (sess_id,user_id,lastlogin,query) VALUES ('" . $sess_id . "','" . $user_id . "',NOW(),'" . $default_val . "')";				

Rögtön beléptetés után berakom neki a default értéket, és ha nem tölti ki az illető a szűrés formot, ezzel fog lefutni a szűrés. Ha igen akkor meg ez van:

results.php


if(!empty($_POST['listCommand'])){
	$listCommand = addslashes($_POST['listCommand']);
	$user_id = $user_data['user_id'];
	$update = "UPDATE manage_session SET query = '".$listCommand."'  WHERE user_id= '".$user_id."' ";
	try {
		$result = DB_class::getInstance ()->query ( $update );
	} catch ( PDOException $e )
	 	{	echo $e->getMessage (); }			
}
else{
	$user_id = $user_data['user_id'];
	$default_val = "nk like \'%\'";
	$update = "UPDATE manage_session SET query = '".$default_val."'  WHERE user_id= '".$user_id."' ";
	try {
		$result = DB_class::getInstance ()->query ( $update );
	} catch ( PDOException $e )
	 	{	echo $e->getMessage (); }		
}

getStudents.php


$user_id = $user_data ['user_id'];
$get_query = "SELECT query FROM manage_session WHERE user_id= '" . $user_id . "' ";
try {
	$result = DB_class::getInstance ()->query ( $get_query );
} catch ( PDOException $e ) {
	echo $e->getMessage ();
}
foreach ( $result as $row ) {
	$query = $row ['query'];
}
$listCommand = stripslashes($query);

A results.php-ban lementem a list.php-ba beállított query-t, majd ezt kiolvasom a getStudents.php-ban és vissza küldöm a list.php-nek és megjelenítem.

szerk: Probléma lehet az, ha a valamilyen mező tartalmaz \ jelet, de szerintem ez nagyon extrém eset. Viszont itt bejön az is, hogy a szerveren be van e kapcsolva a magic qoutes vagy nem, mert ugye az sem mindegy. Mert ha én sql utasítást akarok lementeni muszaj vagyok hozzáadni escape karaktereket a '-jelek miatt. Na de mindegy ez már tényleg hab a tortán. Gondolom mindjárt jön valaki és benyögi, hogy programozásnál minden extrém esetre ki kell térni, mindent le kell kezelni stb... Most megspóroltam ennek az illetőnek egy kört. :)

Ha már validálás, akkor azt már a megfelelő tömbelem érkezésekor megtenném és el se jutna behelyettesítésig, ha nem tetszik amit lát a validátor. De én a saját adatbázisomat úgy készíteném el, hogy a fenti kód validálás nélkül se tehessen kárt benne DROP TABLE és egyéb okosságokkal. Vagyis remélem, a fenti kijelentésed max homokozóban állja meg a helyét.
--
unix -- több, mint kód. filozófia.
Life is feudal

Eloszor is, azt neked kell eldonteni, hogy mi a kovetelmeny, milyen userkent fog futni a webszerver, illetve az adott oldal? (Ez nem mindig ugyanaz.) Mivel a jogokat nem tudod garantalni hogy megmaradnak kulonbozo filerendszereken es mediakon keresztul, ajanlatos pl. egy scriptet az egesz melle csomagolni es dokumentalni ami beallitja a megfelelo jogokat telepiteskor.

A legtobb rendszeren alapbol van egy kimelt user (www-data, www, etc.) ami neveben fut a webszerver es ennek a felhasznalonak kell jogokat adni a fileokhoz.
Normalisan beallitott webszerveren viszont minden oldal kulon user neveben fut, igy nem fernek egymas adataihoz hozza meg akkor sem ha tudjak hol van helyileg esetleg.

Altalanosan, adj:

- Minden php es html filera olvasasi jogot az adott usernek amelyik neveben az oldal futni fog.
- Minden olyan filera amit a php-k irnak ugyanennek a usernek irasi jogot.
- Mindenki masnak 0.
- 777-et gyorsan felejtsd el :)

Most, hogy már nincs fájlba írás akkor mondjuk 750 root:www-data és rekurzívan beállítok minden fájlt mappát root:www-data-ra. Emellett megjegyzem, hogy ha több weboldal fut a szerveren akkor ennél még jobb megoldás, hogy létrehozunk az oldalnak egy külön felhasználót és ő rajta keresztül futtatjuk a webszerverünket és minden fájl-t ami vele kapcsolatos szigorúan az ő tulajdonába helyezünk. Ezt gondolom apache2-mpm-itk -val lehet megoldani, de ilyet még nem csináltam.

én így szoktam, sajnos ha a php apache module-ként fut, akkor nem lesz rá lehetőséged.
Nálam a dolog úgy működik, hogy a www-data user alatt a static file-ok kiszolgálása megy, a php-k domain-enként külön user-el a www-data groupban foglalnak helyet. Így szépen el lehet különíteni mindent és mindenkit

sunmao: Légyszíves vedd komolyan a kritikákat, végigolvastam, de egyik sem volt céltalan belekötés. Nyilván mindannyian követtünk el hibákat amikor még kezdők voltunk, szégyelljük is magunkat miatta, de ez nem kevesbíti a tieidet. Ne legyen ez keserű tapasztalat, inkább tanulópénz.
Amúgy meg (bár ezzel talán sokan nem értenek egyet), a php nem egy elegáns nyelv, nem lehet benne hatékonyan, jó kódot írni, még a tapasztaltaknak is könnyű hibázni, én pl. nem is lennék hajlandó phpben programozni, minek keressem a bajt, különben amúgy is kínszenvedés lenne. Szerintem kezdj el kacsintgatni a "komolyabb" nyelvek irányába. Pl. Java jó választás. Vagy ha mélységet keresel az informatikában, és vállalkozó szellemű vagy, akkor c és később (ez fontos!) ojjektumorientált supersetjei (c++ vagy objective c). Ha annyira nem érdekel, akkor java.

Vagy hamarosan úgyis itt a HOVD, ottani programnyelvek közül kinézel valami szimpatikusat. De szerintem a php -t kerüld el.

Ha valóban végig olvastad az összes postot akkor bizonyára ez a rész sem kerülte el a figyelmed:
"Természetesen semmi baj nincs azzal, ha valaki rámutat a hibáimra. Sőt inkább csak örülök neki, mert ezáltal csak jobbá tehetem a kódomat. Megint más az mikor valaki vagdalkozik ész nélkül és csak fikázza a másikat, emellett semmilyen építő kritikát nem tesz hozzá."

Nem a kritikával van a bajom, hanem azzal ha valaki idejön és ideböfög nekem mindenfélét, mert ő úgy érzi, hogy neki ezt most mindenképpen meg kell tennie. Ezzel az én munkámat nem segíti és majd ha valaki idejön ugyanezzel vagy hasonló problémával az ő dolgát sem fogja megkönnyíteni. Az ilyennek szerintem nincs értelme és nincs is itt helye. Ha valaki mindenképpen flamelni akar akkor keressen magának olyan jellegű topicot és tegye azt meg ott. Tudom, hogy a fórumokon ez lassan már egy külön sportággá nőtte ki magát, de én ebben eddig sem kívántam részt venni és ez után sem fogok.

Most akkor még egyszer. Ha valóban végig olvastad az itt lévő hozzászólásokat, de ha csak az eredeti kérdésemnek akár az első egy mondatát is, akkor abból rájöhettél, hogy ez egy szakdolgozat. Ebből viszont már következtethettél arra, hogy valamilyen felsőoktatási intézményben tanulok. Na most a dolgozat témáját tekintve gyaníthatod, hogy azért mégis csak valami olyan dologgal foglalkozok aminek van köze informatikához. Ha erre már rájöttél, akkor nyilván összeáll a kép, hogy én végzős vagyok valamelyik egyetem informatikai karán. Ha ez meg van akkor szeretnék feltenni egy kérdést. Szerinted egy olyan szakon ahol informatikusnak tanulok, ott a három és fél év alatt nem volt szerencsém találkozni az általad felsorolt nyelvek nagy részével?

Arról pedig, hogy a PHP milyen nyelv az a véleményem, hogy a nyelvvel magával nincs gond. Viszont ha az aki írja a kódot, trehány és nem figyel oda az meg fog látszani a végeredményen is. Viszont lehet PHP-ban is nagyon szépen objektumorientáltan alkotni és aki jó programozó az ebben is tud maradandót alkotni. Tény, hogy más nyelveknél talán kisebb a programozó "szabadsága" és jobban rá van utalva a precízebb/jobb munkára. Abban igazat adok, hogy a túl nagy szabadság mehet a végeredmény rovására de ez megint csak nem a nyelv hibája.

A fentebbi nyelvről alkotott véleményem pedig nem erre a topicra vonatkozik. Mert én nem állítom magamról, hogy programozó vagyok sőt azt sem hogy tudok programozni. Igaz tanultam programozást (habár nem PHP-t) de ez még édes kevés. Emellett szeretném azt is megjegyezni, hogy esetemben nem a trehányságról van szó, hanem csak egyszerű hozzá nem értésről.A PHP nyelvvel 2-3 hónapja kezdtem el foglalkozni a szakdolgozat kapcsán és szerintem pont annyira ártottam bele magam amennyire szükséges volt. Most lehet azzal jönni megint, hogy ez a topic az élő példa, hogy NEM de szerintem ez a fájlos incidens egy hiba volt amit orvosoltam és ezzel is sokat tanultam. Szerintem tökéletes programot nehéz kiadni az embernek a keze közzül, sőt lehet hogy nem is létezik olyan, de törekedni lehet rá. Én úgy érzem törekszem, ez meg lelkiismeret kérdése.

"Szerinted egy olyan szakon ahol informatikusnak tanulok, ott a három és fél év alatt nem volt szerencsém találkozni az általad felsorolt nyelvek nagy részével?"

Fogalmam sincs mit oktatnak az informatikai felsőoktatásban. Az ott tanultak beszámolói alapján az a kép alakult ki bennem, hogy egy-egy nyelvről van egy-két szemeszter, de az alapján csak felszínes tudást lehet szerezni. Nem gondoltam, hogy nem találkoztál pl. javával vagy c++al, hanem azt gondoltam, hogy nem ismeredtél meg vele közelebbbről.
Amúgy szerintem valamivel közelebbről megismerkedni nem is lehet tanórán. Adhat egy alapot, de a lelkesedés fontosabb.