OK, lets try with list. ;-) Where is determined as which user procmail
runs. It's runned from /etc/aliases, owned by root:system. It does not
read anything from user's (listserv, group daemon) like .procmailrc ...
The recipe just pipes mail into wrapper (SUID to root, group daemon)
which calls resend script, which feeds mail into outgoing queue. In the
outgoing queue is performed resending to recipients and local delivery
into archive.
As the problem seems to be, that on working list are these permissions on
archive file and directory: daemon:daemon, 776.
On the list which doesn't work are perms listserv:daemon, 776. Even
changing 766 does not help.
The obvious thing is that I'm sure it worked before. :(
If the problem is in perms of parent directories, no because beween
others:
/usr/majordomo/lists/$LIST.archive
Perms on all /usr/majordomo/lists/ are same.
In /usr/majordomo/lists/$ONE-LIST.archive I have daemon:daemon files,
because it just started now, in th eother I have listserv:daemon.
On Thu, 7 Oct 1999, era eriksson wrote:
On Thu, 7 Oct 1999 18:39:54 +0200 (MET DST), Martin Mokrejs
<mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> wrote:
> Procmail is SUID to root (root:mail). It's being called from
> sendmail.cf as Mlocal program. Procmail runs ar root, how can
> procmail drop into daemon:daemon?
Priveleges are dropped when it drops into delivery mode, always, for
obvious security reasons. It doesn't really drop privileges, it suid:s
to the right user (which root can always do, but you can't change back
then).
(DROPPRIVS is useful in site-wide recipes if you want to drop
priveleges earlier than what would otherwise be the case.)
This is our /etc/procmailrc:
DROPPRIVS=YES
VERBOSE=off
LOGABSTRACT=all
LOGFILE=/scratch/procmail/$LOGNAME.log
PATH="/etc/procmail:/usr/bin:/usr/local/bin:/usr/sbin:$PATH"
SHELL=/bin/sh
PMSRC=/etc/procmail
SECURITY_NOTIFY="postmaster"
SECURITY_NOTIFY_VERBOSE="postmaster"
#Possibly infected by viruses
POISONED_EXECUTABLES=/etc/procmail/poison.list
SCORE_HISTORY=/scratch/procmail/$LOGNAME.score
#Replace `mail' with your mail directory (Pine uses mail, Elm uses Mail)
MAILDIR=$HOME
#Directory for storing procmail log and rc files
PMDIR=$HOME/.procmail
INCLUDERC=/etc/procmail/html-trap.procmail
But is this relevant problem when e-mail is in my case just piped through
programs and then piped into outgoing queue?
The problem with sharing mailboxes across user id:s is that Procmail
is pretty paranoid about loose permissions. If you chmod a mailbox so
it can be shared, Procmail will refuse to deliver there, or chmod it
back before delivering.
I can't come up with a good answer off the top of my head. Perhaps you
should ask this on the list.
OK, I see I can ask root to take over ownership over all archives (make
daemon:daemon), and give rw to listserv:daemon byl setting up ACL's. ;-)
Not a better solution?
Does it means that if there'd be DROPRIVS=no in /etc/procmailrc, that
$HOME/.procmailrc will be executed with root privs? No. Would it help in
this case so that delivery to $LIST.archive/$LIST.YYMM would be performed
as root, so will succeed? No. Am I right that privs would be dropped
anyway before this - because this is delivery?
But on the other hand, this happens while piping data from one queue to
another ... So, what does the "delivery" really mean? ;-)
TIA
--
Martin Mokrejs - PGP 5.0i key at: finger://mail.natur.cuni.cz/mmokrejs
<mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> Faculty of Science, The Charles
University