Problem z funkcją move_upload_files Opcje

[Solaris2001]

Witam. Napisałem sobie skrypt, który wgrywa zdjęcia na serwer, zmienia nazwę, przenosi do katalogu i wykonuje na pliku przekształcenia.
O ile dobrze działał na hoście cba.pl to na ugu.pl jest problem z przeniesieniem pliku z tmp do katalogu. Plik jest wgrywany bo normalnie działają funkcję porówniania rozmiaru, rozszerzenia. Niestety parser nie wywala żadnego błędu, tylko idzie dalej. Czy możecie mi powiedzieć o co chodzi? Poniżej wklejam fragment kodu odpowiedzialny za tą funkcję:

[PHP] pobierz, plaintext 
$max_rozmiar = 3072*1024;
if (isset ($_POST['submit'])){
	if (!empty($_POST['tytul'])){
		if (is_uploaded_file($_FILES['plik']['tmp_name'])) {
			if ($_FILES['plik']['size'] > $max_rozmiar) {
				$info = 'Błąd! Plik jest za duży!';
				$przerwij = true;
			}
			else if ($_FILES['plik']['type']!='image/jpeg'){
				$info = '<span style="color: red;">Niepoprawny format pliku. Akceptowane są pliki tylko z rozszerzeniem <b>.jpg</b>!</span>';
				$przerwij = true;
			}
			else {
				$info = 'Zdjęcie zostało dodane! Skopiuj kod poniżej i wklej go do tematu.';
				$plik_nazwa = nazwa_pliku();
				move_uploaded_file($_FILES['plik']['tmp_name'],$_SERVER['DOCUMENT_ROOT'].'/img/'.$plik_nazwa.'.jpg');
				mysql_query("INSERT INTO `galeria` (`tytul`,`opis`,`autor`,`adres`) VALUES ('".$_POST['tytul']."','".$_POST['opis']."','".$uzytkownik."','http://mpkoc.ugu.pl/img/".$plik_nazwa.".jpg')");
				$kod = "{img}http://mpkoc.ugu.pl/img/".$plik_nazwa."m.jpg{/img}";
			}
		}
...
[PHP] pobierz, plaintext 

$_SERVER['DOCUMENT_ROOT'] - "/virtual/m/p/mpkoc.ugu.pl"
$_FILES['plik']['tmp_name'] - "/virtual/tmp/phpSmiPg6"

Ten post edytował Solaris2001 14.10.2012, 21:04:31

[tab]

dodaj error_reporting(E_ALL) i powiedz jakie błędy Ci wypisuje

[Solaris2001]

Już działa. Chodziło o to, że folder img nie miał ustawionych CHMODów na 777.
Ale dzięki za tą instrukcję, na pewno przyda się.

[cudny]

Już działa. Chodziło o to, że folder img nie miał ustawionych CHMODów na 777.
Ale dzięki za tą instrukcję, na pewno przyda się.

Uprawnienia na 777 to zło !
Utwórz sobie lepiej ten katalog z pozycji php, bedziesz mial pelny dostep.
A jeśli nie to dodaj apacha do grupy z uprawnieniami roota

[abort]

Uprawnienia na 777 to zło !

Bo co, napsuje coś? No to tylko w tym jednym katalogu... Poza tym, CZASAMI można zastosować prawa 1777, ale po co robić małe luki, lepiej zróbmy tak jak proponujesz:

A jeśli nie to dodaj apacha do grupy z uprawnieniami roota

...i wtedy Apache i PHP będą mogły psuć w całym systemie... No chyba że admin był na tyle bystry i przewidujący, że ustawił chroota/jaila.
Nie po to projektanci Apache kupę czasu spędzili nad tym, by serwer nie musiał chodzić z UID=0, by teraz dodawanie Apacha do grup rootowych było panaceum na wszystko.
Nie, to jest jeszcze gorsze rozwiązanie niż chmod 777.

[hedrazer]

jak już to przynajmniej zabrać uprawnienia na executa, read i write wystarczy...

[abort]

I co Ci da zabranie execute? W przypadku pliku - nic. Z reguły nie wrzuca się na serwer binarek plików, poza tym przytomny admin wie, jak w momencie startu systemu zabronić uruchamiania jakichkolwiek niepożądanych binarek, bo czytał manuala do mount.
A w przypadku katalogu zabranie execute skutkuje jednym: niemożliwością wejścia do katalogu i czytania jego zawartości.

Obawiam się, że ze swoimi radami błądzisz we mgle. Przyjmij w dobrej wierze, że 777 na jakiś jeden dedykowany katalog to i tak mała dziura

[cudny]

Bo co, napsuje coś? No to tylko w tym jednym katalogu... Poza tym, CZASAMI można zastosować prawa 1777, ale po co robić małe luki, lepiej zróbmy tak jak proponujesz:

Ale gadasz głupoty - nadawanie uprawnień 777 to nieporozumienie, nadaj jeszcze odpowiednie allowoverride i czekaj co dalej !

...i wtedy Apache i PHP będą mogły psuć w całym systemie... No chyba że admin był na tyle bystry i przewidujący, że ustawił chroota/jaila.
Nie po to projektanci Apache kupę czasu spędzili nad tym, by serwer nie musiał chodzić z UID=0, by teraz dodawanie Apacha do grup rootowych było panaceum na wszystko.
Nie, to jest jeszcze gorsze rozwiązanie niż chmod 777.

Jak psujesz sobie Apachem czy php cokolwiek to może zajmij się czym innym.
Poza tym wystarczy Apachowi nadać uprawnienia do /var/www i tyle

[abort]

Wiesz co? Ograniczanie się do "nadania uprawnień do /var/www" mogą sugerować tylko takie osoby, które nigdy nie administrowały Apachem z virtualkami. Poza tym, prawa 777 na katalog do uploadu zdjęć to jedyne znane mi rozwiązanie - jeśli masz/znasz jakieś inne, to zaprezentuj.
A "psucie" przez Apache i PHP to był mój komentarz do Twojej propozycji nadania praw do grupy z uprawnieniami roota. Z kilku powodów: bo jest to DUPNA dziura w security. Znacznie większa niż 777 na JAKIŚ JEDEN katalog.

A wracając do meritum: zaproponuj jakieś rozwiązanie na problem z pierwszego posta albo zamilcz.

P.S.
Jeśli chcesz, możemy dyskusję przenieść na PW.

[cudny]

A wracając do meritum: zaproponuj jakieś rozwiązanie na problem z pierwszego posta albo zamilcz.

To było nie miłe, a co katalogów z fotkami to ja nigdy tam nie daje 777 ! - wystarczy is_dir( .. ) i utworzyć w razie potrzeby.
Nadawanie uprawnień 777 to dostęp nie tylko dla apache ! Poza tym po co ci prawo do wykonywania plików dla obrazków, co ?
Linux jest bezpieczny właśnie dzięki swoim ograniczonym uprawnieniom dla danych aplikacji / userów !
A dla twojej wiadomości korzystam tylko z VPS, niestety jeszcze nie stać mnie na dedyka.
Tak na prawdę wygodniej i taniej było by hostingować to na jakiś serwisach, ale korzystam nie tylko z apache, ale także z node.js więc potrzebuję pełnego dostępu do serwera.

A na PW nie mam czasu i potrzeby

Ten post edytował cudny 16.10.2012, 13:45:35

[Uriziel01]

To było nie miłe, a co katalogów z fotkami to ja nigdy tam nie daje 777 !

I to że ty nigdy tego nie robisz miało przekonać Twojego dyskutanta ? Nie widzę żadnego horroru w nadaniu (ale jest to EWENTUALNY punkt zainteresowania, to przyznaje), 777, z usuwaniem flagi wykonywalności nie ma co kombinować bo i tak mając w i interpreter PHP'a atakujący może zrobić dosłownie wszystko.

[abort]

To było nie miłe, a co katalogów z fotkami to ja nigdy tam nie daje 777 ! - wystarczy is_dir( .. ) i utworzyć w razie potrzeby.

To nie miało być niemiłe (potrafię być bardziej niemiły) - miało "tylko" spowodować, byś czasem pomyślał o tym, że ktoś inny wypowiadający się na forum TAKŻE może mieć wiedzę - takiej postawy w Twoich wypowiedziach jakoś nie odczułem. Choć z drugiej strony, jeśli poczułeś się urażony, to przepraszam.

Oczywiście, można i tak - choć nie zawsze się da (vhost w katalogu usera i konto z dostępem FTP czy nawet ssh) - Apache działa z innymi prawami dostępu niż ma user poprzez połączenia via ftp/ssh - tu z reguły daje się prawa 777 (lub nawet 1777), choć czasami da się pogłówkować, i zrobić tak, żeby nie dawać 777

Nadawanie uprawnień 777 to dostęp nie tylko dla apache ! Poza tym po co ci prawo do wykonywania plików dla obrazków, co ?

Autor wątku (Solaris2001) napisał w trzecim poście: "Już działa. Chodziło o to, że folder img nie miał ustawionych CHMODów na 777." Musisz dać prawo "x" na katalog, by go odczytać (wylistować czy "wejść" do niego). Najważniejszą rzecz wytłuściłem. Poza tym, o zapobieganiu wykonywania plików (to się robi globalnie dla filesystemu podając flagi dla polecenia 'mount') już w wątku pisałem.

Linux jest bezpieczny właśnie dzięki swoim ograniczonym uprawnieniom dla danych aplikacji / userów !

I rozumiem, że to co proponowałeś, czyli nieograniczone powiększenie praw dostępu dla apache (dodanie go do grupy adminów) jest mniejszym złem niż 777 na JEDEN katalog?