[imp] Weird attachment problem

[Lord Apollyon]

> If I want to attach a file to an e-mail, I'll hit 'browse' and find a
> file.  Then I'll click 'attach' and it'll upload the file, and it'll
> claim it's attached to the message and it'll give filesize, mimetype,
> etc.
> 
> Then I send the file, and there's no attachment.  Some mail readers
> will see an attachment with the appropriate filename but with a size
> of 0 bytes.  Other mail readers (like IMP) will simply say there's no
> attachment.  I can even go to my sent-items folder and it'll claim
> there's no attachment to the file.

This sounds suspiciously like an upload directory permissions problem, a
misconfigured Safe Mode related problem, or a mixture of the two.

You need to figure out what the setting for PHP's upload directory is for
webserver.  If Safe Mode is enabled, then your copy of IMP will need to
match the ownership of that directory, otherwise IMP will be blocked from
touching and handling those files (which will be owned by the UID/GID of the
running webserver process).

Setting safe_mode_gid to TRUE and convincing your admin to chgrp wwwgroup
(or whatever it's called) would resolve this without throwing away Safe Mode
protections.

You're in a tough spot, as a loser-user (as opposed to an administrator). 
The webserver runs as its own UID/GID, which is not root and not you.

You have IMP code owned by you with your UID/GID.  Uploads will always be
owned by the webserver's UID.  You see the problem.

Multi-user installations of PHP usually like to enable Safe Mode to reduce
the likelihood of one user being able to browse and read other users' files
through the PHP file/directory navigation and read calls.

As some may rush forward to protest that Safe Mode is an application-level
"hack" or "fictional access control", I will submit that in the commonly
configured case of Apache installations, this is probably most accessible
method to reduce the attack profile of PHP's file-accessor calls.  Proper
UNIX permissions with its restrictive 3x3 model can only go so far,
especially when coupled with the security contexts in which Apache runs.

With proper ACLs or even perhaps one of the more exotic MPMs
("per-UID/threaded") of Apache 2, this problem could be properly addressed.

=R=