php mail() function not working

Peter L. Peres plp-ysDPMY98cNQDDBjDh4tngg at public.gmane.org
Tue Oct 7 17:42:00 UTC 2003


On Mon, 6 Oct 2003, Keith Mastin wrote:

>
> > What I do when I get lost is cause a php script to create a file in
> > /tmp. This will have the permissions and umask of the cgi executor in
> > that context. This is usually enough to continue with the problem. F.ex.
> > you can su to that user and try to exec sendmail. Also see the
> > install permissions of the relevant libs (libphp, pibZend).
>
> Okay, install permissions is a concept I'm having a problem grasping. Php
> needs to be installed with sendmail permissions. What does this mean? That
> I su - postfix while running make? Or that I do the whole configure, make
> and make install routines as root?

You do all install as root, make and config as whoever you wish, unless
otherwise specified. This is in general for packages that must be
installed system-wide. For packages that install in the user dir, you do
not become root to install (presumably because you can't anyway - being a
luser). This is not your case. There are very few packages that need local
install as luser (unfortunately - this tends to keep the system
clean(er) imho).

> My friend came over earlier and we traced the problem out of php to
> postfix/apache permissions, using a similar method watching the logs and
> top. The /tmp file thing sounds interesting though.

I do not know what Apache mail() does but under postfix all local mail is
injected into sendmail whose permissions should be root.root w/o any suid.
It in turn calls postdrop (the application, not the directory!!!) which
runs SGID postfix and thus has access to the postdrop directory. If mail()
shortcuts these then what you say makes sense. Check your postfix docs for
exact permisson data (postfix check should report problems), my postfix is
old(er).

If there would be a way to make mail() send SMTP to localhost instead of
attempting to deliver it, then it would probably work with any setup, and
leave the mail routing to postfix, and the firewalling to the firewall
(you need not use only port 25 for incoming ...). That way these apps
should stop trampling on each other's permissions and everything should
keep working even if you upgrade something.

F.ex. on my home machine I use pine over POP3/SMTP to connect to the local
postfix/popper daemons instead of local delivery just to avoid locking
problems. It works great, never lost mail, no problems upgrading anything.
The result is that I can open several instances of pine on the
mailbox(es), only one having the lock token (and being able to modify -
all the other instances can only read), I can open TkMail, OpenOffice,
Opera Mail etc. all at the same time (OO will empty the mailbox but will
put the mail back when closing it). Since POP3 is locked by the server
side no problems with concurrent access.  Who needs IMAP ? ;-)

In general I force all the apps to use the localhost or local network for
access, with the exception of system scripts and daemons which post admin
mail using sendmail. This has worked great for my home machine for
serveral years now.

good luck,

Peter
--
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





More information about the Legacy mailing list