imagick und die Rechte...

[Joshh]

Hallo zusammen,

ich möchte mit imagick automatisch Thumbnails von Bildern in einem Verzeichnis erstellen und im Unterverzeichnis "/thumbs" speichern. Das mache ich so:

  
$bild = new Imagick($gallery_folder.$datei);  
$bild->cropThumbnailImage($thumbs_size,$thumbs_size);  
$bild->writeImage($thumbs_folder.$datei);  

Vorher wird geprüft, ob das Unterverzeichnis "/thumbs" existiert. Wenn nicht, wird es erstellt:

  
mkdir($thumbs_folder);  
chmod($thumbs_folder, 0777);  

Der Witz ist jetzt, dass imagick (bzw. writeImage) sich in diesem Fall mit folgender Meldung verabschiedet:

Fatal error: Uncaught exception 'ImagickException' with message 'Safe mode restricts user to read image:

Erstelle ich den thumbs-Ordner per ftp, werden die Thumbs korrekt erstellt und alles ist gut ;-)

Mir ist nicht klar, warum der php-Nutzer nicht in ein selbst erstelltes Verzeichnis schreiben darf, aber dafür in eins, das dem ftp-Nutzer gehört.

Hat jemand einen heißen Tipp für mich?

Gruß
Josh

[Tom]

Hello,

ich möchte mit imagick automatisch Thumbnails von Bildern in einem Verzeichnis erstellen und im Unterverzeichnis "/thumbs" speichern. Das mache ich so:

$bild = new Imagick($gallery_folder.$datei);
$bild->cropThumbnailImage($thumbs_size,$thumbs_size);
$bild->writeImage($thumbs_folder.$datei);

>   
> Vorher wird geprüft, ob das Unterverzeichnis "/thumbs" existiert. Wenn nicht, wird es erstellt:  
>   
> ~~~php
  

> mkdir($thumbs_folder);  
> chmod($thumbs_folder, 0777);  
> 

Der Witz ist jetzt, dass imagick (bzw. writeImage) sich in diesem Fall mit folgender Meldung verabschiedet:

Fatal error: Uncaught exception 'ImagickException' with message 'Safe mode restricts user to read image:

Der Fehler ist ganz klar benannt: Der Safe-Mode ist eingeschaltet.

Dann muss das Script, dass die Manipulation durchführen soll, denselben Owner haben, wie die Datei, die manipuliert werden soll oder das Verzeichnis, in dem sie gespeichert ist.

Daher funktioniert das mit dem durch FTP angelegten Verzeichnis. Das hat den FTP-User als Eigentümer. Das Script wirst Du vermutlich auch mit FTP hochgeladen haben. Dann hat es auch den FTP-User als Owner.

Nun müsstest Du überlegen, wie Du den Owner des Scripts ändern kannst. Das wäre z.B. dadurch zu erreichem, indem Du es auf dem Server einfach mittels eines PHP-Scriptes kopierst.

Das dafür benötigte Kopierscript solltest Du allerdings durch ein langes Passwort schützen, oder hinterher sofort wieder entfernen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Joshh]

Hallo,

Dann muss das Script, dass die Manipulation durchführen soll, denselben Owner haben, wie die Datei, die manipuliert werden soll oder das Verzeichnis, in dem sie gespeichert ist.

Alles klar, das hilft mir schonmal weiter, danke. An den Skript-Besitzer habe ich gar nicht gedacht...

Gruß
Josh

[Joshh]

Hallo,

Dann muss das Script, dass die Manipulation durchführen soll, denselben Owner haben, wie die Datei, die manipuliert werden soll oder das Verzeichnis, in dem sie gespeichert ist.

Nun müsstest Du überlegen, wie Du den Owner des Scripts ändern kannst. Das wäre z.B. dadurch zu erreichem, indem Du es auf dem Server einfach mittels eines PHP-Scriptes kopierst.

Das Kopieren der Datei hat leider nicht den gewünschten Effekt gebracht. Sie gehört jetzt dem php-User, aber die Fehlermeldung bleibt die gleiche. Ist das weil die Bilder, aus denen die Thumbs erstellt werden, dem ftp-User gehören?

Nach meinem Verständnis dürfte Imagick doch nur lesend auf die Originalbilder zugreifen, weil sie ja nicht überschrieben werden, sondern die Thumbs in einer neuen Datei gespeichert werden.
Geht da ImageMagick oder GD vielleicht anders vor? Im Moment erscheint es mir am simpelsten, die Thumbs nicht in einem Unterverzeichnis zu speichern, sondern direkt im Bilderverzeichnis, aber es kann ja eigentlich nicht so kompliziert sein, die einfache Aufgabe "Erstelleunterordnerundmachethumbsrein" ohne großen Pfusch umzusetzen ;-)

Gruß
Josh

[Tom]

Hello,

Das Kopieren der Datei hat leider nicht den gewünschten Effekt gebracht. Sie gehört jetzt dem php-User, aber die Fehlermeldung bleibt die gleiche. Ist das weil die Bilder, aus denen die Thumbs erstellt werden, dem ftp-User gehören?

Ja genau.
Alle betroffenen Dateien und Verzeichnisse müssen demselben User gehören, dem das manipulierende Script gehört.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Das Kopieren der Datei hat leider nicht den gewünschten Effekt gebracht. Sie gehört jetzt dem php-User, aber die Fehlermeldung bleibt die gleiche. Ist das weil die Bilder, aus denen die Thumbs erstellt werden, dem ftp-User gehören?

So ist es. Bei den meisten Hostern hast Du Dich mit zwei verschiedenen System-Usern herumzuschlagen.

Einmal gibt es Dich als Kunden, mit einer eigenen User-ID und einem eigenen User-Namen, der sich oft aus Kundennummer und/oder erster Domain ableitet. Dann gibt es den User, unter dem der Webserver läuft. Der heißt meistens www oder wwwrun, gelegentlich auch apache, und hat oft die User-ID 80. Diese Details sind eigentlich unwichtig, wichtig ist nur, dass der Webserver unter einer anderen User-ID läuft.

Wenn PHP innerhalb des Webserver-Prozesses läuft (mod_php & Co), was sehr oft der Fall ist, dann läuft PHP unter dem Webserver-User, nicht unter Deiner User-ID. Das ist auch der Hauptgrund für den "Safe Mode" von PHP, denn normalerweise gibt es keinen Unterschied, für welchen Kunden PHP gerade Dateien oder Verzeichnisse liest. Ohne den Safe-Mode könnte jeder Kunde in allen anderen Kunden-Dateien herumstöbern, die dem Webserver-User zugänglich sind. Das sind bei Massenhostern in der Regel alle Dateien, inklusive DB-Passworten. Je nach Rechtevergabe könnte man auch in fremde Verzeichnisse schreiben.

Die Alternative heißt, für jeden Kunden einen eigenen PHP-Interpreter laufen zu lassen, oft als Kombination aus suEXEC und PHP im CGI-Modus. Damit läuft PHP unter dem jeweiligen Kunden-Account und das Betriebssystem verhindert, dass sich die Kunden gegenseitig ausspionieren (so lange die Kunden nicht so dämlich sind, explizit chmod 0777 auszuführen). Leider ist PHP in diesem Modus deutlich langsamer und verbraucht mehr Resourcen, was für die Hoster weniger Kunden pro Server und damit weniger Umsatz pro Server bedeutet.

Alexander

[Alexander (HH)]

Moin Moin!

Vorher wird geprüft, ob das Unterverzeichnis "/thumbs" existiert. Wenn nicht, wird es erstellt:

mkdir($thumbs_folder);
chmod($thumbs_folder, 0777);

>   
  

> Hat jemand einen heißen Tipp für mich?  
  
Wo prüfst Du, ob mkdir erfolgreich ist?  
  
Wo prüfst Du, ob chmod erfolgreich ist?  
  
Warum gibst Du jedem Benutzer Vollzugriff auf das Verzeichnis? chmod 0777 ist kein Allheilmittel, sondern Cargo Cult. PHP-Voodoo, wenn Du so willst. Keiner weiß, warum man es macht, aber jeder glaubt, dass es hilft. 0700 sollte ausreichen, 0755 geht auch noch. Je nach Server-Einstellung erzeugt mkdir automatisch 0755, 0711, oder 0700, und es gibt kaum einen sinnvollen Grund, daran etwas zu ändern.  
  
Alexander

-- 
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".

[Joshh]

Hallo,

Wo prüfst Du, ob mkdir erfolgreich ist?

Ich prüfe zuvor, ob ich im Bilderordner Schreibrechte habe (mit is_writable) und später nochmal, ob das mit mkdir erstellte Verzeichnis existiert (mit isdir).
Im ftp-Client sehe ich auch, dass der thumbs-Ordner erstellt wurde, das er dem php-Benutzer gehört und chmod 777 hat.

Warum gibst Du jedem Benutzer Vollzugriff auf das Verzeichnis? chmod 0777 ist kein Allheilmittel, sondern Cargo Cult. PHP-Voodoo, wenn Du so willst. Keiner weiß, warum man es macht, aber jeder glaubt, dass es hilft. 0700 sollte ausreichen, 0755 geht auch noch. Je nach Server-Einstellung erzeugt mkdir automatisch 0755, 0711, oder 0700, und es gibt kaum einen sinnvollen Grund, daran etwas zu ändern.

Da muss ich Dir Recht geben, das habe ich nur gemacht, um auszuschließen, dass es an zu geringen Rechten liegt.
Mir war bisher nicht klar, dass im Safe-Mode trotz 777 der Besitzer noch eine Rolle spielt.

Gruß
Josh

[Tom]

Hello,

Im ftp-Client sehe ich auch, dass der thumbs-Ordner erstellt wurde, das er dem php-Benutzer gehört und chmod 777 hat.

Nur mal, weil mich das immer schon nervt. "chmod" (Change Mode) ist der Name des Programmes, mit dessen Hilfe der Rechte-Modus der Dateien und der Verzeichnisse geändert werden kann. Wenn die Datei also etwas hat, dann den Rechtestatus 777, (file rights mode).

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Im ftp-Client sehe ich auch, dass der thumbs-Ordner erstellt wurde, das er dem php-Benutzer gehört und chmod 777 hat.

Nur mal, weil mich das immer schon nervt. "chmod" (Change Mode) ist der Name des Programmes, mit dessen Hilfe der Rechte-Modus der Dateien und der Verzeichnisse geändert werden kann. Wenn die Datei also etwas hat, dann den Rechtestatus 777, (file rights mode).

"File mode", nicht "file rights mode". Und darin steckt noch viel mehr als nur Permissions: Sticky, SetUID, SetGID, Typ (Datei, Verzeichnis, Symlink, Char Device, Block Device, FIFO, Socket). Siehe z.B. Linux stat(2):

The following flags are defined for the st_mode field:

S_IFMT      0170000   bit mask for the file type bit fields
  S_IFSOCK    0140000   socket
  S_IFLNK     0120000   symbolic link
  S_IFREG     0100000   regular file
  S_IFBLK     0060000   block device
  S_IFDIR     0040000   directory
  S_IFCHR     0020000   character device
  S_IFIFO     0010000   FIFO
  S_ISUID     0004000   set UID bit
  S_ISGID     0002000   set-group-ID bit (see below)
  S_ISVTX     0001000   sticky bit (see below)
  S_IRWXU     0000700   mask for file owner permissions
  S_IRUSR     0000400   owner has read permission
  S_IWUSR     0000200   owner has write permission
  S_IXUSR     0000100   owner has execute permission
  S_IRWXG     0000070   mask for group permissions
  S_IRGRP     0000040   group has read permission
  S_IWGRP     0000020   group has write permission
  S_IXGRP     0000010   group has execute permission
  S_IRWXO     0000007   mask for permissions for others (not in group)
  S_IROTH     0000004   others have read permission
  S_IWOTH     0000002   others have write permission
  S_IXOTH     0000001   others have execute permission

The set-group-ID bit (S_ISGID) has several special uses. For a directory it indicates that BSD semantics is to be used for that directory: files created there inherit their group ID from the directory, not from the effective group ID of the creating process, and directories created there will also get the S_ISGID bit set. For a file that does not have the group execution bit (S_IXGRP) set, the set-group-ID bit indicates mandatory file/record locking. The sticky bit (S_ISVTX) on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process.

Der chmod-Syscall und das gleichnamige Programm können davon die letzten vier Stellen in der Oktal-Darstellung, sprich die 12 niederwertigsten Bits, ändern. Die restlichen vier Bits sind für einen einmal angelegten Dateisystem-Eintrag konstant.

Alexander

[Alexander (HH)]

Moin Moin!

Hallo,

Wo prüfst Du, ob mkdir erfolgreich ist?

Ich prüfe zuvor, ob ich im Bilderordner Schreibrechte habe (mit is_writable) und später nochmal, ob das mit mkdir erstellte Verzeichnis existiert (mit isdir).

Und warum zum Geier prüfst Du nicht den Rückgabewert von mkdir()?

Mal so am Rande: Hast Du mkdir im PHP-Manual gelesen? Dann hättest Du Dir das chmod komplett sparen können.

Mir war bisher nicht klar, dass im Safe-Mode trotz 777 der Besitzer noch eine Rolle spielt.

Auch das steht direkt in der Dokumentation von mkdir.

Alexander

[Joshh]

Hallo,

Und warum zum Geier prüfst Du nicht den Rückgabewert von mkdir()?

Oh mann, scheinbar mag ich es wohl kompliziert, danke für den Hinweis ;-)

Mal so am Rande: Hast Du mkdir im PHP-Manual gelesen? Dann hättest Du Dir das chmod komplett sparen können.

Das hatte ich gelesen, aber mit
mkdir($thumbs_folder, 0777);
waren die Rechte trotzdem nur bei 0755. Das liegt wohl an umask, dessen Sinn ich noch nicht ganz durchschaut habe. Beschäftige mich erst seit Kurzem mit php...

Per ftp habe ich versucht, das Setuid-Bit des Bilderverzeichnisses zu setzen. Damit gehört das darin erstellte thumbs-Verzeichnis automatisch dem selben Benutzer, oder? Erfolgreich war ich damit aber nicht, ist daran auch der Safe-Mode schuld? (--> In addition, you cannot set the SUID, SGID and sticky bits)

Gruß
Josh

[Tom]

Hello,

Mal so am Rande: Hast Du mkdir im PHP-Manual gelesen? Dann hättest Du Dir das chmod komplett sparen können.

Das hatte ich gelesen, aber mit
mkdir($thumbs_folder, 0777);
waren die Rechte trotzdem nur bei 0755. Das liegt wohl an umask, dessen Sinn ich noch nicht ganz durchschaut habe. Beschäftige mich erst seit Kurzem mit php...

Die umask ist eine adminsitrative Maßnahme der Linux/Unix-Shell.
http://www.linux-praxis.de/lpic1/manpages/umask.html

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

Und warum zum Geier prüfst Du nicht den Rückgabewert von mkdir()?

Oh mann, scheinbar mag ich es wohl kompliziert, danke für den Hinweis ;-)

(Fast) JEDER Syscall hat ein definiertes Fehlerverhalten, sehr oft wird ein besonderer Wert zurückgegeben, oft 0 oder negative Werte; gelegentlich gibt ein Syscall normalerweise 0 zurück, im Fehlerfall von 0 verschiedene Werte.

Die über der Syscall-Schnittstelle liegende libc verpackt die Syscalls, macht sie gelegentlich etwas hübscher oder kompatibel zu älteren Versionen, benimmt sich aber im großen und ganzen genauso.

Das darüber liegende PHP macht noch einmal das gleiche, ebenso wie viele andere auf C aufbauenden Sprachen. Java schmeißt als größere Ausnahme von der Regel meistens eine Exception, wenn etwas schiefgeht.

Dein Job als Code-Sklave ist es, auf das Fehlerverhalten zu reagieren. Wie einzelne Funktionen im Fehlerfall reagieren, steht in der Dokumentation.

Mal so am Rande: Hast Du mkdir im PHP-Manual gelesen? Dann hättest Du Dir das chmod komplett sparen können.

Das hatte ich gelesen, aber mit
mkdir($thumbs_folder, 0777);
waren die Rechte trotzdem nur bei 0755. Das liegt wohl an umask, dessen Sinn ich noch nicht ganz durchschaut habe.

Ganz einfach: Im Normalfall schreibt man (auf Unix-Systemen) Software so, dass Dateien (plain file, directory, socket, fifo, usw.) immer mit maximalen Rechten angelegt werden, d.h. Verzeichnisse mit 0777, Dateien mit 0666. Der Kernel macht dann noch eine Und-Verknüpfung mit dem negierten umask-Wert, bevor er wirklich mit dem Wert arbeitet. Normalerweise ist das System so eingestellt, dass es einen umask-Wert 022 benutzt, damit werden Dateien mit 0644 und Verzeichnisse mit 0755 angelegt. Wenn Du als paranoider Benutzer einmal in der Shell den umask-Wert umstellst, z.B. auf 077, gilt das für alle ab dem Zeitpunkt gestarteten Programme, d.h. ohne ein Bit am Code zu ändern, werden Dateien dann mit 0600, Verzeichnisse mit 0700 angelegt.

Beschäftige mich erst seit Kurzem mit php...

Das ist keine Entschuldigung, die Doku nicht zu lesen.

Per ftp habe ich versucht, das Setuid-Bit des Bilderverzeichnisses zu setzen. Damit gehört das darin erstellte thumbs-Verzeichnis automatisch dem selben Benutzer, oder?

Oder: "The setuid permission set on a directory is ignored on UNIX and Linux systems. FreeBSD can be configured to interpret it analogously to setgid, namely, to force all files and sub-directories to be owned by the top directory owner."

Erfolgreich war ich damit aber nicht, ist daran auch der Safe-Mode schuld? (--> In addition, you cannot set the SUID, SGID and sticky bits)

Der Safe Mode verhindert, dass Du die drei Bits per PHP setzen kannst. An der Wirksamkeit bzw. Unwirksamkeit der Bits ändert er nichts.

Alexander

[Tom]

Hello,

(Fast) JEDER Syscall hat ein definiertes Fehlerverhalten, sehr oft wird ein besonderer Wert zurückgegeben, oft 0 oder negative Werte; gelegentlich gibt ein Syscall normalerweise 0 zurück, im Fehlerfall von 0 verschiedene Werte.

[...]

Das darüber liegende PHP macht noch einmal das gleiche, [...]

PHP macht etwas sehr dummes: es lässt die substantiierte Fehlernummer verschwinden und tauscht sie gegen einen hart codierten Text aus. Für diese Texte habe ich bis heute noch keine qualifizierte Übersicht gefunden, man muss sie sich also aus dem C-Quellcode rausfummeln, wenn man sie alle haben will und wissen will, in welchem Zusdammenhang sie ausgegeben werden.

Dann kann man dann mühevoll mittels $php_errormsg und der Einstellung für "track_errors = on" (unf ggf. die Unterdrückung der direkten Fehlerausgabe mit '@') wieder auf die Fehlerursache zurückführen.

http://php.net/manual/de/reserved.variables.phperrormsg.php

Ich hoffe, dass die liiiieben PHP-Entwickler in der nächsten Version die Möglichkeit qualifizierter Fehlernummern einführen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Alexander (HH)]

Moin Moin!

PHP macht etwas sehr dummes: es lässt die substantiierte Fehlernummer verschwinden und tauscht sie gegen einen hart codierten Text aus. Für diese Texte habe ich bis heute noch keine qualifizierte Übersicht gefunden, man muss sie sich also aus dem C-Quellcode rausfummeln, wenn man sie alle haben will und wissen will, in welchem Zusdammenhang sie ausgegeben werden.

Ach, ich liebe Perl immer mehr ...

$! liefert im String-Kontext eine Fehlermeldung, im numerischen Kontext eine Fehlernummer (aus errno). Außerdem gibt es $@ für eval, dessen Strings dokumentiert sind.

Alexander

[Joshh]

Hallo,

Beschäftige mich erst seit Kurzem mit php...

Das ist keine Entschuldigung, die Doku nicht zu lesen.

Nein - nur dass ich sie _noch_ nicht gelesen habe ;-)

Bei umask hatte ich den Sinn und Zweck aber auch nach dem Lesen der Doku nicht ganz durchschaut. Da war Deine Erklärung sehr hilfreich.

Das ganze habe ich jetzt so gelöst: Die Thumbs werden direkt im Bilderverzeichnis gespeichert mit dem Zusatz "thumb_" am Anfang des Dateinamens. So kann ich ebenfalls leicht zwischen Thumb und Galeriebild unterscheiden. Den Bilderordner muss ich das Recht 0777 geben.

Jetzt muss ich nur Bilder hochladen und die Galerie mit Thumbs (allmählich hasse ich das Wort ;-)) wird automatisch erzeugt.

Gruß
Josh

[MudGuard]

Hi,

ich möchte mit imagick automatisch Thumbnails von Bildern in einem Verzeichnis erstellen und im Unterverzeichnis "/thumbs" speichern. Das mache ich so:

Dir ist aber schon bewußt, daß "/thumbs" ein Verzeichnis direkt im Root des Filesystems ist?

Fatal error: Uncaught exception 'ImagickException' with message 'Safe mode restricts user to read image:

Naja, dann wirst Du wohl im Savemode nicht auf das Verzeichnis thumbs im Root zugreifen dürfen.

Erstelle ich den thumbs-Ordner per ftp, werden die Thumbs korrekt erstellt und alles ist gut ;-)

Aber dann erstellst Du ihn vermutlich nicht wirklich als "/thumbs", sondern in einem Verzeichnis, auf das Du und PHP (trotz safe-mode) Zugriff haben.

Mir ist nicht klar, warum der php-Nutzer nicht in ein selbst erstelltes Verzeichnis schreiben darf, aber dafür in eins, das dem ftp-Nutzer gehört.

Weil das Verzeichnis, das Du per PHP anlegst, an einer Stelle liegt, die Du nicht erwartest.

cu,
Andreas

[Joshh]

Hi Andreas,

ich möchte mit imagick automatisch Thumbnails von Bildern in einem Verzeichnis erstellen und im Unterverzeichnis "/thumbs" speichern. Das mache ich so:

Dir ist aber schon bewußt, daß "/thumbs" ein Verzeichnis direkt im Root des Filesystems ist?

Jep, ist mir bewusst, da war meine Beschreibung missverständlich. Der Ordner wurde auch per php an der richtigen Stelle erzeugt. Nur konnte mein Thumbs-Erstell-Skript dann keine Bilder darin speichern, weil das Verzeichnis "thumbs" den falschen Owner hat.

Mir ist nicht klar, warum der php-Nutzer nicht in ein selbst erstelltes Verzeichnis schreiben darf, aber dafür in eins, das dem ftp-Nutzer gehört.

Weil das Verzeichnis, das Du per PHP anlegst, an einer Stelle liegt, die Du nicht erwartest.

Nein, siehe oben.

Gruß
Josh