Hallo zusammen, ich möchte unter Verwendung einer aliases pipe ein PHP-Script triggern, welches eine eingehende Mail verarbeitet, und bekomme ein "permission denied", sobald ein "require_once" getriggert wird (php interpreter).
Verwendete Software: Horde Groupware -> Modul "Whups" (Tickettracking) -> "whups-mail-filter" Der gesamte Vorgang ist schon sehr kleinteilig durch die Horde Mailingliste gegangen, weil ich zunächst von einem Fehler dort ausging. Hier der letzte Teil des Troubleshootings:
In der main.cf habe ich den Wert "default_privs = postfix-pipe" gesetzt. Den Benutzer habe ich angelegt. Die Webanwendung residiert unter /var/www/horde Die fragliche Datei (require_once) unter /var/www/horde/whups/lib/Application.php Ab ../horde/.. gilt: 750 www-data:www-horde Die Benutzer "postfix" und "postfix-pipe" sind Mitglieder der Gruppe "www-horde". Die /etc/aliases sieht so aus: ## WHUPS queue links whups: "|/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld]e -Q 5"
In der Datei "/usr/bin/whups-mail-filter" habe ich zu Debuggingzwecken diese Zeilen am Anfang eingefügt $shellex = shell_exec("logger INFO whoami: $(whoami)"); $shellex = shell_exec("logger INFO who am i: $(who am i)"); $shellex = shell_exec("touch /tmp/hallowelt.ini");
Für das weitere Debugging habe ich eine Datei "testmail" angelegt mit diesem Inhalt: ###################### From: root@derdapp001.[mydn.tld] To: whups@[mydn.tld] subject: Monitoring: Testticket
Hello World
####################### Jetzt kann ich mit dem Befehl "sudo -u postfix-pipe cat testmail|/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld] -Q 5" den Vorgang auf der Kommandozeile testen und bekomme im Whups Ticket System mein gewünschtes Ticket. Nun gehe ich auf ein drittes System und sende von dort die "scharfe" E-Mail -also jetzt triggere ich den postfix: ##################### root@derdapp001 ~ # sendmail whups@[mydn.tld] subject: monitoring: testticket
Hallo welt
[ctrl]+d ####################### Jetzt bekomme ich im syslog des mail server diesen output: ######################### ## Mar 12 13:35:27 derdapp004 logger: INFO whoami: postfix-pipe Mar 12 13:35:27 derdapp004 logger: INFO who am i: <=Anmerkung: leer: kein "parent user" Mar 12 13:35:27 derdapp004 postfix/local[16770]: BE46441CCB: to=whups@localhost, orig_to=<whups@[mydn.tld]>, relay=local, delay=0.95, delays=0.02/0.01/0/0.92, dsn=5.3.0, status=bounced (Command died with status 255: "/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld] -Q 5". Command output: PHP Warning: require_once(/var/www/horde/whups/lib/Application.php): failed to open stream: Permission denied in /usr/bin/whups-mail-filter on line 77 PHP Fatal error: require_once(): Failed opening required '/var/www/horde/whups/lib/Application.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/bin/whups-mail-filter on line 77 ) Mar 12 13:35:27 derdapp004 postfix/cleanup[16769]: B13E641CD6: message-id=<20180312123527.B13E641CD6@[mydn.tld]> Mar 12 13:35:27 derdapp004 postfix/bounce[16774]: BE46441CCB: sender non-delivery notification: B13E641CD6 Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: B13E641CD6: from=<>, size=3250, nrcpt=1 (queue active) Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: BE46441CCB: removed Mar 12 13:35:27 derdapp004 dovecot: lda(no-reply@[mydn.tld]): msgid=<20180312123527.B13E641CD6@[mydn.tld]>: saved mail to INBOX Mar 12 13:35:27 derdapp004 postfix/pipe[16777]: B13E641CD6: to=<no-reply@[mydn.tld]>, orig_to=<root@[mydn.tld]>, relay=dovecot, delay=0.14, delays=0.02/0.01/0/0.12, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: B13E641CD6: removed ## ############################ Aus dem "touch" entsteht diese Datei: ################# ## ll /tmp/hallo* -rw------- 1 postfix-pipe postfix-pipe 0 Mar 12 13:35 hallowelt.ini ## ################# Wie zu sehen ist, funktioniert der Aufruf des "require_once" in der whups-mail-filter auf die Application.php nicht. Es scheint das System nicht zu interessieren, welcher Benutzer dort hinterlegt ist. Alle offensichtlichen Zeichen, zeigen klar, daß der Benutzer "postfix-pipe" Verwendung findet. In der Kommandozeile hat dieser auch ordenlichen Zugriff. Nur aus dem Postfix heraus, klappt es nicht. Wenn ich ein 755 auf das horde-verzeichnis gebe -also "other" = "read&execute" gebe, so funktioniert es. Das kann aber wohl nicht als ernsthafte Lösung gesehen werden, oder?
Ich habe noch zwei straces auf den Process. Hier der output, wenn ich aus dem postfix komme: #################### ### [...snip...] gettimeofday({1520811096, 605233}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec64008) = -1 EACCES (Permission denied) gettimeofday({1520811096, 605766}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec63f18) = -1 EACCES (Permission denied) gettimeofday({1520811096, 606180}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec65fe0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups/lib", 0xbec65ee0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups", 0xbec65df0) = -1 EACCES (Permission denied) lstat64("/var/www/horde", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/var/www/horde/whups/lib/Application.php", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) [...snip...] ### #################### und der gleiche Teil, wenn ich aus der Kommandozeile per "sudo -u" komme: #################### ### [...snip...] ettimeofday({1520812051, 622266}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", {st_mode=S_IFREG|0770, st_size=9232, ...}) = 0 lstat64("/var/www/horde/whups/lib", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www/horde/whups", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www/horde", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 gettimeofday({1520812051, 624126}, NULL) = 0 open("/var/www/horde/whups/lib/Application.php", O_RDONLY|O_LARGEFILE) = 4 [...snip...] ### ####################
Wer hat hier eine Idee, was die Ursache ist? Übersehe ich noch etwas? Welche Debug Information kann ich noch liefern? Gruss Carsten
Welche user/group und permissions haben denn diese beiden Verzeichnisse?
lstat64("/var/www/horde/whups/lib", 0xbec65ee0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups", 0xbec65df0) = -1 EACCES (Permission denied)
Am 2018-03-12 13:59, schrieb Carsten:
Hallo zusammen, ich möchte unter Verwendung einer aliases pipe ein PHP-Script triggern, welches eine eingehende Mail verarbeitet, und bekomme ein "permission denied", sobald ein "require_once" getriggert wird (php interpreter).
Verwendete Software: Horde Groupware -> Modul "Whups" (Tickettracking) -> "whups-mail-filter" Der gesamte Vorgang ist schon sehr kleinteilig durch die Horde Mailingliste gegangen, weil ich zunächst von einem Fehler dort ausging. Hier der letzte Teil des Troubleshootings:
In der main.cf habe ich den Wert "default_privs = postfix-pipe" gesetzt. Den Benutzer habe ich angelegt. Die Webanwendung residiert unter /var/www/horde Die fragliche Datei (require_once) unter /var/www/horde/whups/lib/Application.php Ab ../horde/.. gilt: 750 www-data:www-horde Die Benutzer "postfix" und "postfix-pipe" sind Mitglieder der Gruppe "www-horde". Die /etc/aliases sieht so aus: ## WHUPS queue links whups: "|/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld]e -Q 5"
In der Datei "/usr/bin/whups-mail-filter" habe ich zu Debuggingzwecken diese Zeilen am Anfang eingefügt $shellex = shell_exec("logger INFO whoami: $(whoami)"); $shellex = shell_exec("logger INFO who am i: $(who am i)"); $shellex = shell_exec("touch /tmp/hallowelt.ini");
Für das weitere Debugging habe ich eine Datei "testmail" angelegt mit diesem Inhalt: ###################### From: root@derdapp001.[mydn.tld] To: whups@[mydn.tld] subject: Monitoring: Testticket
Hello World
####################### Jetzt kann ich mit dem Befehl "sudo -u postfix-pipe cat testmail|/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld] -Q 5" den Vorgang auf der Kommandozeile testen und bekomme im Whups Ticket System mein gewünschtes Ticket. Nun gehe ich auf ein drittes System und sende von dort die "scharfe" E-Mail -also jetzt triggere ich den postfix: ##################### root@derdapp001 ~ # sendmail whups@[mydn.tld] subject: monitoring: testticket
Hallo welt
[ctrl]+d ####################### Jetzt bekomme ich im syslog des mail server diesen output: ######################### ## Mar 12 13:35:27 derdapp004 logger: INFO whoami: postfix-pipe Mar 12 13:35:27 derdapp004 logger: INFO who am i: <=Anmerkung: leer: kein "parent user" Mar 12 13:35:27 derdapp004 postfix/local[16770]: BE46441CCB: to=whups@localhost, orig_to=<whups@[mydn.tld]>, relay=local, delay=0.95, delays=0.02/0.01/0/0.92, dsn=5.3.0, status=bounced (Command died with status 255: "/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld] -Q 5". Command output: PHP Warning: require_once(/var/www/horde/whups/lib/Application.php): failed to open stream: Permission denied in /usr/bin/whups-mail-filter on line 77 PHP Fatal error: require_once(): Failed opening required '/var/www/horde/whups/lib/Application.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/bin/whups-mail-filter on line 77 ) Mar 12 13:35:27 derdapp004 postfix/cleanup[16769]: B13E641CD6: message-id=<20180312123527.B13E641CD6@[mydn.tld]> Mar 12 13:35:27 derdapp004 postfix/bounce[16774]: BE46441CCB: sender non-delivery notification: B13E641CD6 Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: B13E641CD6: from=<>, size=3250, nrcpt=1 (queue active) Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: BE46441CCB: removed Mar 12 13:35:27 derdapp004 dovecot: lda(no-reply@[mydn.tld]): msgid=<20180312123527.B13E641CD6@[mydn.tld]>: saved mail to INBOX Mar 12 13:35:27 derdapp004 postfix/pipe[16777]: B13E641CD6: to=<no-reply@[mydn.tld]>, orig_to=<root@[mydn.tld]>, relay=dovecot, delay=0.14, delays=0.02/0.01/0/0.12, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 12 13:35:27 derdapp004 postfix/qmgr[16757]: B13E641CD6: removed ## ############################ Aus dem "touch" entsteht diese Datei: ################# ## ll /tmp/hallo* -rw------- 1 postfix-pipe postfix-pipe 0 Mar 12 13:35 hallowelt.ini ## ################# Wie zu sehen ist, funktioniert der Aufruf des "require_once" in der whups-mail-filter auf die Application.php nicht. Es scheint das System nicht zu interessieren, welcher Benutzer dort hinterlegt ist. Alle offensichtlichen Zeichen, zeigen klar, daß der Benutzer "postfix-pipe" Verwendung findet. In der Kommandozeile hat dieser auch ordenlichen Zugriff. Nur aus dem Postfix heraus, klappt es nicht. Wenn ich ein 755 auf das horde-verzeichnis gebe -also "other" = "read&execute" gebe, so funktioniert es. Das kann aber wohl nicht als ernsthafte Lösung gesehen werden, oder?
Ich habe noch zwei straces auf den Process. Hier der output, wenn ich aus dem postfix komme: #################### ### [...snip...] gettimeofday({1520811096, 605233}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec64008) = -1 EACCES (Permission denied) gettimeofday({1520811096, 605766}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec63f18) = -1 EACCES (Permission denied) gettimeofday({1520811096, 606180}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec65fe0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups/lib", 0xbec65ee0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups", 0xbec65df0) = -1 EACCES (Permission denied) lstat64("/var/www/horde", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/var/www/horde/whups/lib/Application.php", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) [...snip...] ### #################### und der gleiche Teil, wenn ich aus der Kommandozeile per "sudo -u" komme: #################### ### [...snip...] ettimeofday({1520812051, 622266}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", {st_mode=S_IFREG|0770, st_size=9232, ...}) = 0 lstat64("/var/www/horde/whups/lib", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www/horde/whups", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www/horde", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 gettimeofday({1520812051, 624126}, NULL) = 0 open("/var/www/horde/whups/lib/Application.php", O_RDONLY|O_LARGEFILE) = 4 [...snip...] ### ####################
Wer hat hier eine Idee, was die Ursache ist? Übersehe ich noch etwas? Welche Debug Information kann ich noch liefern? Gruss Carsten
Welches Betriebssystem setzt du ein? Unter debian-basierten Systemen läuft der Postfix meist chrooted, vielleicht könnte das das Problem sein.
root@derdapp004 ~www/horde/whups/lib # uname -a Linux derdapp004 3.4.113-bananian #9 SMP PREEMPT Sat May 6 12:20:11 UTC 2017 armv7l GNU/Linux
root@derdapp004 ~www/horde/whups/lib # ps -ef|grep postfix root 2124 1 0 Mar11 ? 00:00:02 /usr/lib/postfix/master postfix 16757 2124 0 13:33 ? 00:00:00 qmgr -l -t unix -u postfix 16765 2124 0 13:34 ? 00:00:00 tlsmgr -l -t unix -u -c postfix 17738 2124 0 13:46 ? 00:00:00 anvil -l -t unix -u -c postfix 24447 2124 0 15:13 ? 00:00:00 pickup -l -t unix -u -c postfix 24906 2124 0 15:17 ? 00:00:00 smtpd -n smtp -t inet -u -c -o stress= -s 2 postfix 25657 2124 0 15:28 ? 00:00:00 smtpd -n smtp -t inet -u -c -o stress= -s 2
Update aus einem weiteren Test (C&P von der Horde mailing List): ################# ## I reworked the permissions on the tree as follows: / : drwxr-xr-x 16 root root /var /var : drwxr-xr-x 4 root root 4096 May 6 2017 www /var/www : drwxr-xr-x 24 www-data www-horde 4096 Mar 7 11:33 horde /var/www/horde : drwxr-xr-x 13 www-data www-horde 4096 Mar 7 11:33 whups /var/www/horde/whups : drwxr-xr-x 14 www-data www-horde 4096 Mar 7 11:33 lib /var/www/horde/whups/lib : -rwxr-x--- 1 postfix-pipe www-horde 9232 Mar 11 18:55 Application.php
Pointing out the changes: set 755 from "var" down to "lib" and changed owner of "Application.php" to "postfix-pipe".
=>> This version works.
If I set the owner of "Application.php" back to "www-data" it fails again. Just to make sure, the group member ship is correct: ######################## ## root@derdapp004 ~www/horde/whups/lib # groups postfix-pipe postfix-pipe : postfix-pipe www-horde ## ########################
It seems to ignore the group member ship, if triggered by postfix aliases.
## #############
Am 12.03.2018 um 15:17 schrieb Marco Dickert:
Welches Betriebssystem setzt du ein? Unter debian-basierten Systemen läuft der Postfix meist chrooted, vielleicht könnte das das Problem sein.
Am 12.03.2018 um 15:33 schrieb Carsten:
root@derdapp004 ~www/horde/whups/lib # uname -a Linux derdapp004 3.4.113-bananian #9 SMP PREEMPT Sat May 6 12:20:11 UTC 2017 armv7l GNU/Linux
root@derdapp004 ~www/horde/whups/lib # ps -ef|grep postfix root 2124 1 0 Mar11 ? 00:00:02 /usr/lib/postfix/master postfix 16757 2124 0 13:33 ? 00:00:00 qmgr -l -t unix -u postfix 16765 2124 0 13:34 ? 00:00:00 tlsmgr -l -t unix -u -c postfix 17738 2124 0 13:46 ? 00:00:00 anvil -l -t unix -u -c postfix 24447 2124 0 15:13 ? 00:00:00 pickup -l -t unix -u -c postfix 24906 2124 0 15:17 ? 00:00:00 smtpd -n smtp -t inet -u -c -o stress= -s 2 postfix 25657 2124 0 15:28 ? 00:00:00 smtpd -n smtp -t inet -u -c -o stress= -s 2
Update aus einem weiteren Test (C&P von der Horde mailing List): ################# ## I reworked the permissions on the tree as follows: / : drwxr-xr-x 16 root root /var /var : drwxr-xr-x 4 root root 4096 May 6 2017 www /var/www : drwxr-xr-x 24 www-data www-horde 4096 Mar 7 11:33 horde /var/www/horde : drwxr-xr-x 13 www-data www-horde 4096 Mar 7 11:33 whups /var/www/horde/whups : drwxr-xr-x 14 www-data www-horde 4096 Mar 7 11:33 lib /var/www/horde/whups/lib : -rwxr-x--- 1 postfix-pipe www-horde 9232 Mar 11 18:55 Application.php
Pointing out the changes: set 755 from "var" down to "lib" and changed owner of "Application.php" to "postfix-pipe".
=>> This version works.
If I set the owner of "Application.php" back to "www-data" it fails again. Just to make sure, the group member ship is correct: ######################## ## root@derdapp004 ~www/horde/whups/lib # groups postfix-pipe postfix-pipe : postfix-pipe www-horde ## ########################
It seems to ignore the group member ship, if triggered by postfix aliases.
## #############
Am 12.03.2018 um 15:17 schrieb Marco Dickert:
Welches Betriebssystem setzt du ein? Unter debian-basierten Systemen läuft der Postfix meist chrooted, vielleicht könnte das das Problem sein.
Hi noch einmal, der Hinweis mit dem chroot hat mich animiert in diese Richtung zu suchen (ich bin jetzt nicht DER Linux Experte, daher bitte ich um Nachsicht). Also, es scheint einen Zusammenhang zu geben. Wenn ich die Datei "whups-mail-filter" um diese Zeile erweitere: ".. $shellex = shell_exec("logger INFO my id: $(id)"); $shellex = shell_exec("logger INFO my groups: $(groups)"); .." bekomme ich im syslog diese Ausgabe: "... Mar 12 17:56:42 derdapp004 logger: INFO my id: uid=1001(postfix-pipe) gid=1002(postfix-pipe) groups=1002(postfix-pipe) Mar 12 17:56:42 derdapp004 logger: INFO my groups: postfix-pipe ..."
Ja, postfix ist chrooted in der master.cf. Jetzt habe angefangen, zu experimentieren, aber bis jetzt hat nichts geholfen. Zum Beispiel habe ich einfach mal die "/etc/passwd" und die "/etc/group" in das Verzeichnis "/var/spool/postfix/etc" kopiert und postfix neu gestartet. Leider ohne eine sichtbare Änderung. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
Any ideas?
Gruss Carsten
On 12.03.2018 20:29, Carsten wrote:
Ja, postfix ist chrooted in der master.cf. Jetzt habe angefangen, zu experimentieren, aber bis jetzt hat nichts geholfen. Zum Beispiel habe ich einfach mal die "/etc/passwd" und die "/etc/group" in das Verzeichnis "/var/spool/postfix/etc" kopiert und postfix neu gestartet. Leider ohne eine sichtbare Änderung. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
SELinux oder so kommt nicht zusätzlich ins Spiel, oder ist SELinux nur ein Feature von RHEL basierten Linuxen, was bei Dir ja nicht der Fall ist ...
Walter
Am 12.03.2018 um 21:52 schrieb Walter H.:
On 12.03.2018 20:29, Carsten wrote:
Ja, postfix ist chrooted in der master.cf. Jetzt habe angefangen, zu experimentieren, aber bis jetzt hat nichts geholfen. Zum Beispiel habe ich einfach mal die "/etc/passwd" und die "/etc/group" in das Verzeichnis "/var/spool/postfix/etc" kopiert und postfix neu gestartet. Leider ohne eine sichtbare Änderung. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
SELinux oder so kommt nicht zusätzlich ins Spiel, oder ist SELinux nur ein Feature von RHEL basierten Linuxen, was bei Dir ja nicht der Fall ist ...
Walter
Hallo, SELinux hatte ich auch schon mal im Verdacht, ebenso, wie Apparmor, aber SELinux ist nicht aktiviert und Apparmor nur für den mysql deffiniert. und es bleibt ja im Raum, daß es von der Kommandozeile -also ohne den chroot; funktioniert.
Gruss Carsten
Am 13.03.2018 um 08:34 schrieb Carsten:
Am 12.03.2018 um 21:52 schrieb Walter H.:
On 12.03.2018 20:29, Carsten wrote:
Ja, postfix ist chrooted in der master.cf. Jetzt habe angefangen, zu experimentieren, aber bis jetzt hat nichts geholfen. Zum Beispiel habe ich einfach mal die "/etc/passwd" und die "/etc/group" in das Verzeichnis "/var/spool/postfix/etc" kopiert und postfix neu gestartet. Leider ohne eine sichtbare Änderung. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
SELinux oder so kommt nicht zusätzlich ins Spiel, oder ist SELinux nur ein Feature von RHEL basierten Linuxen, was bei Dir ja nicht der Fall ist ...
Walter
Hallo, SELinux hatte ich auch schon mal im Verdacht, ebenso, wie Apparmor, aber SELinux ist nicht aktiviert und Apparmor nur für den mysql deffiniert. und es bleibt ja im Raum, daß es von der Kommandozeile -also ohne den chroot; funktioniert.
Gruss Carsten
Moin nochmal, ich bekomm' hier echt einen an der Waffel -gibt Menschen, die behaupten, ich hätte da schon eine kleben ;-)
chroot oder nicht chroot. Das ist hier die Frage. Laut syslog ist dieser Prozess: "postfix/local" für das Ausführen der aliases Pipe zuständig -zumindest wird es so im Syslog gemeldet: "..Mar 13 11:08:06 derdapp004 postfix/local[10609]: 8D8E741E10: to=whups@localhost, ..."
Schaue ich nun in die master.cf, so steht dort in der Zeile für den local: ".... discard unix - - - - - discard local unix - n n - - local virtual unix - n n - - virtual ..." was sich für mich ließt, daß er NICHT im chroot läuft. Warum sollte also der Prozess die /etc/group nicht ziehen, wie die Ausgabe von $(groups) im Script vermuten läßt: "... #!/usr/bin/php <?php $shellex = shell_exec("logger INFO whoami: $(whoami)"); $shellex = shell_exec("logger INFO who am i: $(who am i)"); $shellex = shell_exec("logger INFO my id: $(id)"); $shellex = shell_exec("logger INFO my groups: $(groups)"); $shellex = shell_exec("touch /tmp/hallowelt.ini"); ..." ergibt: "... Mar 13 11:08:06 derdapp004 logger: INFO whoami: postfix-pipe Mar 13 11:08:06 derdapp004 logger: INFO who am i: Mar 13 11:08:06 derdapp004 logger: INFO my id: uid=1001(postfix-pipe) gid=1002(postfix-pipe) groups=1002(postfix-pipe) Mar 13 11:08:06 derdapp004 logger: INFO my groups: postfix-pipe ..."
Komme ich aus der Kommandozeile mit einem "... sudo -u postfix-pipe /tmp/testmail ..." steht im syslog: "... Mar 13 11:19:24 derdapp004 logger: INFO whoami: postfix-pipe Mar 13 11:19:24 derdapp004 logger: INFO who am i: Mar 13 11:19:24 derdapp004 logger: INFO my id: uid=1001(postfix-pipe) gid=1002(postfix-pipe) groups=1002(postfix-pipe),1001(www-horde) Mar 13 11:19:25 derdapp004 logger: INFO my groups: postfix-pipe www-horde ..."
Inhalt der /tmp/testmail: "... echo "From: root@[mydn.tld]_ To: whups@[mydn.tld]_ subject: Monitoring: Testticket_ _ Hello World_ _"|/usr/bin/whups-mail-filter -g -a carsten@[mydn.tld] -Q 5; ..."
Ich habe die MANPAGES von Postfix jetzt rauf und runter gelesen, aber irgendwas muss ich übersehen, oder?
Ich bin.... not amused.... gruss Carsten
Am 2018-03-12 20:29, schrieb Carsten:
Ja, postfix ist chrooted in der master.cf. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
Gar nicht. Das bei chroot angegebene Verzeichnis wird für diesen Prozess (und alle Subprozesse) zum "root", du hast keinen Zugriff mehr auf alles was außerhalb davon ist. Dir fehlt also nicht nur dein PHP Script, sondern der ganze PHP Interpreter und alles was der so benötigt (config, Libraries, Datenbank, usw.). Für das was du vor hast darfst du Postfix nicht mit chroot laufen lassen.
Am 13.03.2018 um 08:01 schrieb J. Fahrner:
Am 2018-03-12 20:29, schrieb Carsten:
Ja, postfix ist chrooted in der master.cf. Die Frage scheint also lauten zu müssen: Wie bekomme ich den chroot des postfix dazu, eine group-datei zu lesen?
Gar nicht. Das bei chroot angegebene Verzeichnis wird für diesen Prozess (und alle Subprozesse) zum "root", du hast keinen Zugriff mehr auf alles was außerhalb davon ist. Dir fehlt also nicht nur dein PHP Script, sondern der ganze PHP Interpreter und alles was der so benötigt (config, Libraries, Datenbank, usw.). Für das was du vor hast darfst du Postfix nicht mit chroot laufen lassen.
Hallo Die Aussage kann so nicht stimmen. Dann würde er das "whups-mail-filter" ja überhaupt nicht ziehen und das tut er. Sonst hätte ich die Ausgabe der Zeilen ".. $shellex = shell_exec("logger INFO my id: $(id)"); $shellex = shell_exec("logger INFO my groups: $(groups)"); .." ja gar nicht im syslog zu sehen bekommen: "... Mar 12 17:56:42 derdapp004 logger: INFO my id: uid=1001(postfix-pipe) gid=1002(postfix-pipe) groups=1002(postfix-pipe) Mar 12 17:56:42 derdapp004 logger: INFO my groups: postfix-pipe ..."
Und die Fehlermeldung in dieser Form wäre auch nicht existent: "... Mar 8 12:40:38 derdapp004 postfix/local[30799]: 04C7040C4C: to=whups@localhost, orig_to=<whups@[mydn.tdl]>, relay=local, delay=0.58, delays=0.09/0.04/0/0.45, dsn=5.3.0, status=bounced (Command died with status 255: "/usr/bin/whups-mail-filter -g". Command output: PHP Warning: require_once(/usr/share/php/www/horde/whups/lib/Application.php): failed to open stream: No such file or directory in /usr/bin/whups-mail-filter on line 73 PHP Fatal error: require_once(): Failed opening required '/usr/share/php/www/horde/whups/lib/Application.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/bin/whups-mail-filter on line 73 ) ..."
Auch würde ich dann im strace kein "permission denied" sehen, sondern ein "not found" "... [...snip...] gettimeofday({1520811096, 605233}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec64008) = -1 EACCES (Permission denied) gettimeofday({1520811096, 605766}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec63f18) = -1 EACCES (Permission denied) gettimeofday({1520811096, 606180}, NULL) = 0 lstat64("/var/www/horde/whups/lib/Application.php", 0xbec65fe0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups/lib", 0xbec65ee0) = -1 EACCES (Permission denied) lstat64("/var/www/horde/whups", 0xbec65df0) = -1 EACCES (Permission denied) lstat64("/var/www/horde", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0 lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/var/www/horde/whups/lib/Application.php", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) [...snip...] ..."
Also "gar nicht" im Sinne dieser Grundlage kann nicht stimmen.
Gruss Carsten
Also "gar nicht" im Sinne dieser Grundlage kann nicht stimmen.
Ich habe dir nur die grundlegende Funktion von chroot beschrieben. Um dein seltsames Verhalten zu erklären müsste man wissen, welche Prozesse Postfix mit chroot laufen lässt, und welche nicht. Alle können es offensichtlich nicht sein, da manches ja gefunden wird. Aber das Wissen wird dir nicht helfen, denn du kannst das Verhalten ja nicht ändern.
Daher bleibt meine Empfehlung: schalte das chroot aus, du wirst nicht froh damit.
hallo zusammen,
ein herzliches Danke für die Unterstützung. Die Lösung gibt es hier:
https://inoculat0r.blogspot.de/2018/03/postfix-and-secondary-group-issue-wit...
;-)
Am 13.03.2018 um 13:45 schrieb J. Fahrner:
Also "gar nicht" im Sinne dieser Grundlage kann nicht stimmen.
Ich habe dir nur die grundlegende Funktion von chroot beschrieben. Um dein seltsames Verhalten zu erklären müsste man wissen, welche Prozesse Postfix mit chroot laufen lässt, und welche nicht. Alle können es offensichtlich nicht sein, da manches ja gefunden wird. Aber das Wissen wird dir nicht helfen, denn du kannst das Verhalten ja nicht ändern.
Daher bleibt meine Empfehlung: schalte das chroot aus, du wirst nicht froh damit.
participants (4)
-
Carsten -
J. Fahrner -
Marco Dickert -
Walter H.