PHP && Permissions, ...czyli chmod'y w PHPie Opcje

[Skie]

Witam,
natrafiłem na dość dziwny błąd, z którym nie mogę sobie poradzić.
Otóż w ostatnim czasie jednemu z użytkowników serwisu wyskoczył taki błąd podczas przeglądania podstron.

Kod

Warning: fopen(./includes/data/equipment/to_add/239.txt) [function.fopen]: failed to open stream: Permission denied in [xxx]/equipment.php on line 682

Są 2 wyjścia czemu taki błąd się pojawił - najczęstszy jest taki, że plik nie istnieje, lecz kod w tym fragmencie wygląda tak:

[PHP] pobierz, plaintext 
    $filePath = './includes/data/equipment/to_add/'.$player -> id.'.txt';
    if (file_exists($filePath) && ($filesize = filesize($filePath)) > 0) {
      $file = fopen($filePath, 'a+');
      $json = fread($file, $filesize);
      $json = json_decode($json, true);
      $countJSON = count($json);
      fclose($file);
 
      // [...]
   }  
[PHP] pobierz, plaintext 

Skoro if się wykonał znaczy że plik istniał, gdyż przeszedł przez file_exists();

Pozostaje więc 2 wyjście - nieodpowiednie uprawnienia plików - ale dlaczego?
Pliki w tym folderze są nadzorowane przez PHPa - sam je tworzy, edytuje, odczytuje etc. Folder w którym znajdują się te pliki ma uprawnienia 777.
Ponadto jest tam tych plików dużo dużo więcej i błąd pojawił się dotychczas jedynie 2 razy - co by znaczyło że 2 razy zawiodły uprawnienia?

Przy 1 wyjściu jest jeszcze ekstremalna teoria, że 2 skrypty zostały odpalone przez tego samego użytkownika tak ekstremalnie blisko siebie, że mogły same sobie zazgrzytać - ale to jest raczej niemożliwe.

Co może być powodem takiego dziwnego zachowania skryptu?

Z góry dziękuję za odpowiedź.

Ten post edytował Skie 11.08.2010, 11:48:16

[toel]

Nie mam co do tego pewności, ale czy to nie jest tak, że na serwerze może być ustawiony defaultowy chmod dla nowych plików ?

Spróbuj ustawić chmod zaraz po utworzeniu pliku, przez chmod()

[Skie]

Czytałeś co pisałem? To nie jest błąd, który pojawia się często. Przez rok działania serwisu pojawił się 2 razy (w ciągu ost. miesiąca oba przypadki).
Jeżeli byłaby to wina uprawnień to każdy plik powodowałby błąd. Nowo stworzone pliki otrzymują chmod 644 i we wszystkich przypadkach to wystarcza by PHP mógł z nimi robić co mu się podoba.
Jakaś inna koncepcja?

Ten post edytował Skie 11.08.2010, 11:59:46

[erix]

[quote]Co może być powodem takiego dziwnego zachowania skryptu?[/quote[
Rozumiem, że cały czas na tym samym serwerze? Jak jest skonfigurowany? FastCGI, jeśli dobrze myślę?

[Skie]

Tak, ten sam serwer.
Jako moduł apache.

[Pilsener]

239.txt

- co to jest za plik i skąd się bierze? Jeśli jest tworzony "w locie" przez PHP to możemy mieć problemy na niektórych serwerach! By tego uniknąć zalecam najpierw tworzenie pustego pliku przez touch, a nie fopen.

Potem sprawdzam:
- czy plik istnieje
- czy jest is_readable/is_writable etc.
- czy można go otworzyć

Przy plikach warto też robić kopie (a najlepiej trzymać je w bazie, by zawsze móc przywrócić w razie potrzeby), często plik np. cfg jest odtwarzany a klient nawet tego nie zauważa Zawartość pliku bywa często tracona przy próbie jego edycji, warto też mieć jakąś procedurę awaryjną na wypadek uszkodzenia pliku, jest plik 239.txt, który zawiera jakieś znaki i nie można nic z nim zrobić - gdy nie udaje się go usunąć/przywrócić leci mail do admina, by zrobił to przez ftp lub w bashu

skrypty zostały odpalone przez tego samego użytkownika tak ekstremalnie blisko siebie, że mogły same sobie zazgrzytać

- i tak i nie. Jeśli ktoś zapisuje plik to jest on blokowany na czas zapisu (przynajmniej tak powinno być), oczywiście blokowanie nie powinno dotykać w żaden sposób userów, którzy tylko odczytują plik, ale moze akurat tu jest inaczej?

Kiedyś pracowałem dużo z plikami i nauczyłem się, że plikom nie należy ufać i co jakiś czas któryś wypada z szeregu a już makabra gdy przychodzi pracować z plikami pod obciążeniem (równoczesny insert i update) lub na kiepskiem hostingu (częste pady i zrywanie łącza)

[erix]

Jeśli jest tworzony "w locie" przez PHP to możemy mieć problemy na niektórych serwerach! By tego uniknąć zalecam najpierw tworzenie pustego pliku przez touch, a nie fopen.

Mógłbyś rozwinąć?

[Pilsener]

Oczywiście. Spotkałem się z tym głównie na darmowych hostingach gdzie trzeba było robić coś na plikach (brak bazy). Gdy plik był tworzony przez fopen i zapisywany z jakąś treścią było niby ok, ale okazywało się, że nie możemy zmienić chmodów temu plikowi ani pobrać go przez ftp! Był jakby "zawieszony" czy też nałożoną miał jakąś kwarantannę/ograniczenia (to najczęstszy przypadek z jakim miałem styczność), z kolei na innym darmowym hostingu plik był tworzony ale pusty i nie dało rady nic zapisać bez ręcznej zmiany chmodów (przez ftp'a), z kolei jeszcze jeden przypadek z jakim się spotkałem, to nie tworzenie pliku w ogóle. Natomiast z touch nie miałem nigdy żadnych problemów.

Na 99% na lepszych hostingach nie byłoby takich problemów, ale lubię testować aplikację na " bardzo tanim hostingu od super Z!0muuff", bo jak pójdzie u nich to pójdzie wszędzie

[erix]

Darmowe hostingi mają uwalone PHP, zacznijmy od tego...

Stawiam, że było włączone safe_mode, a omijam hostingi z adminami, którzy nie potrafią skonfigurować suPHP/suexec/jailowanego FastCGI.