php mail() function not working

[Keith Mastin]

<quote who="Fraser Campbell">
> On Tuesday 07 October 2003 12:01, serge_ss-rieW9WUcm8FFJ04o6PK0Fg at public.gmane.org wrote:
>> Well, the security implications are understandable, but what's the
>> solution if sendmail and other stuff are run under apache user, and su
>> .... -c '/usr/sbin/sendmail -t -i' doesn't work. The only other
>> solution I see, is to write a stub that would accept input from php
>> and then send it to postfix under different privileges.

The pipe solution we were talking about.  I'm not convinced it's
necessary. I still think the hint is in the php compilation instructions,
to compile php with user privileges for sendmail.

> /usb/sbin/sendmail can be run by any user on the system, no need to su,
> no  need for it to be suid/sgid (we're talking postfix systems here not
> necessarily others).

My sendmail binary is set 755, so yes, it should be executable by any
user. If executed by apache though, the process hangs at the handoff to
postdrop.

>                     Programs such as /bin/mail, pine, mutt, php, etc.
> all  use this program directly, users running those programs should not
> be members  of the postdrop group.
>
> As I understand it, /usr/sbin/sendmail passes mail to a program called
> postdrop for further processing.  Taking a stab at Keith's problem I
> guessed  that his postdrop binary is not setgid postdrop, if that is the
> case he will  definitely get a permission denied message when running
> /usr/sbin/sendmail  (and consequently postdrop).

-rwxr-sr-x    1 root     postdrop   359703 Sep 10 15:32 /usr/sbin/postdrop

> On a redhat system you should probably have these permissions seem
> typical:
>
>     /usr/sbin/sendmail.postfix, owner root:root, mode 555 (or 755)
755 root

> /usr/sbin/postdrop, owner root:postdrop, mode 2555 (or 2775)
2755 root.postdrop

>     /var/spool/postfix/maildrop/, owner postfix:postdrop, mode 730
630 postfix.postdrop, reset to 1730

That was so simple, and it bugs me that it wasn't documented anywhere. I
have (and read/refer to) the Blum book, I'm a member of the users list,
read all the docs pretty much extensively, yet there's no replacement for
good old tlug. :)

Unfortunately, it didn't fix the problem. Unless apache is a member of the
postfix and postdrop groups, the message hangs in a memory process because
of permissions problems.

Throwing another curve ball is the fact that mod_auth_pam is needed for
.htaccess for hundreds of users on 2 domains hosted on the server. I had
to change the user that apache runs under from apache to shadow-readers.



--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml