"Stefan Monnier"
<monnier+lists/procmail(_at_)TEQUILA(_dot_)SYSTEMSZ(_dot_)CS(_dot_)YALE(_dot_)EDU>
wrote:
- I still haven't figured out how to deal with mode-775 mailspool. If I
DROPPRIVS before delivering, it can't write to the dir (and hence can't lock
the .lock file and can't create a mailbox file if there wasn't one already).
If I deliver before DROPPRIVS'ing, it works fine (of course) except that the
file that gets created is owned by root.root instead of <user>.mail.
I guess the idea is that the files have to be created some other way and then
to deliver without .lock locking, is that right ?
Not necessarily. Why not simply call a chown after delivering?
(when the error message
"procmail: Lock failure on "/var/spool/mail/news.lock" appears does it mean
that no locking took place or does it mean that it reverted to plain
kernel-locking ?)
If kernel-locking is enable, it still used it. If even that fails,
the message is different.
- Actually the above example is a little wrong: I only use a 775 dir for a
backup-mailspool and the main delivery file is /var/mail/$LOGNAME/mailbox.
I slightly extended procmail so that it can be configured to do the right
thing. Basically, the normal concat(MAILSPOOLDIR, MAILHASH, LOGNAME) is
extended into concat(MAILSPOOLDIR, MAILHASH, LOGNAME, MAILDIRFILE) with the
default MAILDIRFILE being "". I've encountered the following problems:
I'll look into what you did.
--
Sincerely,
srb(_at_)cuci(_dot_)nl
Stephen R. van den Berg (AKA BuGless).
Warning: Dates in calendar are closer than they appear.