467,917 Members | 1,346 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,917 developers. It's quick & easy.

Webmail Clients and Permissions

Setup:
Red Hat Linux 8.0
Apache 1.3.27
PHP 4.3.2
Sendmail 8.11.6

Other Info:
root:root /var/spool/mail
root:root /var/spool/mqueue
Apache running as nobody:nobody

Installations of everything in the "default" locations.

The Issue:
Using (a) a PHP-based webmail client and (b) the PHP mail() function,
I cannot seem to get both to be able to access the mqueue directory to
write temp files. For example, with the above setup, the webmail
clients work fine, however a simple mail("me@thathost.com","Test
Subject","Test Message","From: me@thishost.com") is refused permission
to write to mqueue. If I change ownership of mqueue to nobody:nobody,
the simple mail() function works, but the webmail cannot get
permission to write its mqueue file.

maillog Error (with ownership set to root:root, mail() failing):

SYSERR(nobody): Can't create transcript file ./xxx: Permission denied
SYSERR(nobody): Cannot create ./xx2: Permission denied
from=nobody, size=0, class=0, nrcpts=0, relay=nobody@localhost"

(Substitute (root) for (nobody) when I switch ownership to
nobody:nobody, causing webmail to fail.)

Sorry, but please note again that when I change ownership on mqueue to
nobody:nobody, the PHP mail() function works fine.

I have tried several PHP webmail clients (BasiliX, NOCC, etc.) with
the same results. I have tried running Apache as root (not allowed,
and not safe anyway), as nobody (current condition), and as a
user:group I created just for mail stuff, with the same or worse
results.

Does anyone have any idea how I can get the mail() function to execute
with permissions to access that dang mqueue directory while it is
owned by root:root? I would sure appreciate any tips. Thanks!
Jul 16 '05 #1
  • viewed: 3654
Share:
2 Replies
Okay...I'm upgrading to Apache 2 and Sendmail 8.12.9. I'll follow-up
after that, hopefully with good news!

st**********@hotmail.com (James Butler) wrote in message news:<5e**************************@posting.google. com>...
Setup:
Red Hat Linux 8.0
Apache 1.3.27
PHP 4.3.2
Sendmail 8.11.6

Other Info:
root:root /var/spool/mail
root:root /var/spool/mqueue
Apache running as nobody:nobody

Installations of everything in the "default" locations.

The Issue:
Using (a) a PHP-based webmail client and (b) the PHP mail() function,
I cannot seem to get both to be able to access the mqueue directory to
write temp files. For example, with the above setup, the webmail
clients work fine, however a simple mail("me@thathost.com","Test
Subject","Test Message","From: me@thishost.com") is refused permission
to write to mqueue. If I change ownership of mqueue to nobody:nobody,
the simple mail() function works, but the webmail cannot get
permission to write its mqueue file.

maillog Error (with ownership set to root:root, mail() failing):

SYSERR(nobody): Can't create transcript file ./xxx: Permission denied
SYSERR(nobody): Cannot create ./xx2: Permission denied
from=nobody, size=0, class=0, nrcpts=0, relay=nobody@localhost"

(Substitute (root) for (nobody) when I switch ownership to
nobody:nobody, causing webmail to fail.)

Sorry, but please note again that when I change ownership on mqueue to
nobody:nobody, the PHP mail() function works fine.

I have tried several PHP webmail clients (BasiliX, NOCC, etc.) with
the same results. I have tried running Apache as root (not allowed,
and not safe anyway), as nobody (current condition), and as a
user:group I created just for mail stuff, with the same or worse
results.

Does anyone have any idea how I can get the mail() function to execute
with permissions to access that dang mqueue directory while it is
owned by root:root? I would sure appreciate any tips. Thanks!

Jul 16 '05 #2
Got it. I did not, yet, upgrade Sendmail, although I did upgrade
Apache...but that wasn't the problem.

I made /var/spool/mqueue GROUP-writable. Since "nobody" was not the
owner of the directory, but IS in the "root" group, this simple chmod
fixed the problem.

Thanks!
Jul 16 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Jonathan Ives | last post: by
reply views Thread by Mike | last post: by
3 posts views Thread by Bengt Richter | last post: by
reply views Thread by Christopher Brandsdal | last post: by
reply views Thread by joe | last post: by
9 posts views Thread by MaSTeR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.