|
Re: Executing a program as a recipient from ~/.procmailrc
2003-02-08 16:08:38
At 16:58 2003-02-08 -0500, Louis LeBlanc wrote:
> DROPPRIVS is meaningless if the user it is delivering as _is_ root (or
> whoever the MTA invokes the PROG mailer as). Procmail has no _user_ to
But I am running procmail with -m.
Goodie. You're invoking it FROM where? Within sendmail running
_as_root_. if procmail isn't being told to run as if it were the LDA
(whether it IS the LDA or not), then it isn't going to assume a userid,
even if that's one of the arguments you throw on the commandline (see the
docs for -m -- all the arguments after the rcfile are simply expanded to
$1, $2... args - no special meaning is assigned to any of them, even if one
of them just happens to be a userid).
It is invoked as follows from
sendmail.cf:
procmail -Y -m /etc/procmailrc $u $h
Once again, this is an inadequate picture of how you are invoking it -
surely, there is a ruleset encompassing this? Is this from an Mlocal
definition (oh, I really hope not), an Mprocmail definition (typically
totally unnecessary unless you're writing your own sendmail rulesets, but
it is often included by people enabling any option in their MC file
pertaining to procmail), or in the midst of a sendmail ruleset? Under what
conditions would the above actually be invoked?
And the /etc/procmailrc file is used.
Well, in this case, obviously - it's the rcfile you're
_specifying_. However, if you specified any other rcfile with the -m
param, /etc/procmailrc WOULD NOT be automatically invoked because that's
how procmail works. See the manpage - this *IS* documented.
What I meant about /etc/procmailrc not being invoked is that if you invoked
_some_other_ rcfile (using -m), that since it wasn't being invoked as an
LDA (via mlocal rule, and more specifically, with the -d param which makes
it act like an LDA), procmail wouldn't be running /etc/procmailrc.
It still stands that the way you're invoking the rcfile, procmail is
running AS _root_ (or whatever user the MTA is running as, but from your
comments, we can safely conclude that is root), and doesn't have a
different uid to switch to (not having been told that with '-d $u'). If
you were using an /etc/procmailrcs/someuserowned.rc, procmail would be able
to assume the id of the owner of that file, and from there, INCLUDERC the
/etc/procmailrc (though that won't be executed elevated to root, I'm afraid).
It must be, otherwise all the changes I've been making to it over the last
several years wouldn't have modified behavior.
Tell me, for users whose email is invoked with procmail as the LDA (that
is, not being invoked manually in a ruleset, or via an alias running a
PROGRAM), do these people have problems? I suspect not.
You're having problems BECAUSE you're invoking procmail as root and
expecting that changing the invocation parameters will actually have it
behaving the same. The params are what define _how_ procmail acts.
Get a six pack of Jolt(tm) and guzzle it down, wait a few minutes
(presuming that you don't enter a diabetic shock), then re-read my previous
post.
I'm afraid I'm feeling a little slow here. If I understand this
correctly, /etc/procmailrc should be owned by root, moved to
/usr/local/etc/procmailrcs/procmailrc, and should then INCLUDERC a
NO, NO, NO.
/etc/procmailrc
is a FILE. That SPECIFIC file (path and name) has special meaning to
procmail WHEN RUN AS THE LDA (via mlocal ruleset). See the manpages.
/etc/procmailrcs/
is a DIRECTORY, which that specific directory path has special meaning to
procmail when invoked with files within that directory - it will assume the
identity of the owner of whatever rcfile is being run within that
directory. Again, see the manpages.
Thus, if you have a sendmail rule or alias, and you want it to run
something AS A SPECIFIC user, you should place the rcfile within
/etc/procmailrcs/ and provide that path to procmail.
*THAT* rcfile can contain a line such as:
INCLUDERC=/etc/procmailrc
to invoke the /etc/procmailrc rules. However, I don't _believe_ (not
having a need to do this myself) that procmail would for any reason
"re-assume" root perms when running the _included_ /etc/procmailrc
file. That'd be a serious security breach anyway, since running something
as an unprivledged user who could change operational variables THEN include
a root'ed rcfile which would behave differently would pose serious problems.
file (like ~/.procmailrc) owned by the user I want it to switch to.
And of course, the sendmail invocation should be more like
procmail -Y -m /usr/local/etc/procmailrcs/procmailrc $u $h
FTR, just in case you missed it, /usr/local/... isn't /etc/procmailrcs/
The procmail manpage makes specific reference to excluding parent
references, (/etc/procmailrcs/../../home/schmuck/gotcha.rc for instance),
and by a similar token, I expect that links from other directory paths
probably don't fly, even if the file might eventually have a link in
/etc/procmailrcs/.
> (the -d option to procmail should also be of interest to you, but since
you
I read that section:
[snip - manpage excerpt]
Procmail will setuid to the intended
recipients and delivers the mail as if it were
invoked by the recipient with no arguments (i.e., if
no rcfile is found, delivery is like ordinary mail).
Re-read that several times please. Out loud, deliberatley enunciating the
words.
The question is wether this would hose the delivery that actually
happens at the end of the system wide procmailrc (currently
/etc/procmailrc)?
SPECIFICALLY, it'll handle the /etc/procmailrc just as it would if procmail
were invoked as the LDA. If that means you're delivering via
/etc/procmailrc instead of dropping through to the ~/.procmailrc (please
refer to your SUBJECT line), then that's how it'll deliver.
For reference, a typical mlocal invocation of procmail (directly from
sendmail's own procmail_local feature exansion) would be:
procmail -Y -a $h -d $u
That '-d $u' is what makes procmail act like an LDA, and that's exactly
what makes it invoke /etc/procmailrc first (processed as root), check for a
~/.procmailrc file (processed as $u), and all that.
Refer to the manpage for the meaning of the switches, and to the sendmail
documentation for the intended contents of the variables.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
|
|