On 24 Sep, Philip Guenther wrote:
| Don Hammond <procmail3(_at_)tradersdata(_dot_)com> writes:
| >On 24 Sep, Philip Guenther wrote:
| >| [...]
| >| >DROPPRIVS=no
| >|
| >| DROPPRIVS has no effect outside of the /etc/procmailrc file, so you
| >| can remove it from here.
| >| [...]
| >
| >Apologies for the question, since this is clear. I need to be sure.
| >Is this also true for files in /etc/procmailrcs/ specifically
| >INCLUDERC'ed from /etc/procmailrc? Thank you.
|
| Hmm, let me rephrase: the DROPPRIVS variable only has an effect when it is
| set during the "rcfile parsing sequence" started by the automatic parsing
| of the /etc/procmailrc file. If you use INCLUDERC or SWITCHRC from the
| /etc/procmailrc file, it'll still have an effect from them. It's not
| the name of the rcfile that matters but rather the step in the processing.
|
| So the answer to your question is "yes". Note that the /etc/procmailrcs/
| path has a special meaning to procmail and in general should not be used
| for any other purpose. Putting other rcfiles in that directory may open
| security holes on your system!
I'm not trying to be dense (promise), but this doesn't answer it for
me. Maybe a brief explanation and example will help. This is with
procmail v3.13.1.
My mail server is primarily for a one person home office, and also
takes care of the family's needs. There are no outside "untrusted"
users. Much of what I do on the family's behalf is user specific, but
I'm the only one who can do it. It would more typically be done from
each ~/.procmailrc, but is done from /etc/procmailrc to make it easier
for me to maintain. Rather than having one monolithic /etc/procmailrc
file, it's broken down in more modular fashion. All these other pieces
are in /etc/procmailrcs/, most being INCLUDERC'ed from /etc/procmailrc,
some from other files in /etc/procmailrcs/, and none from anywhere else.
In all cases /etc/procmailrc is the ultimate parent - procmail is called
as local mailer, not as "general purpose mail filter" with -m.
So for example, from /etc/procmailrc I do:
RCDIR=/etc/procmailrcs
:0
* LOGNAME ?? ^^deh^^
{ INCLUDERC=$RCDIR/lists.deh.rc }
If that file identifies a list message, it does:
INCLUDERC=$RCDIR/listokrc
which, among other things, does:
DROPPRIVS=yes
INCLUDERC=$SKIPTORC
[SKIPTORC is set in an earlier contortion, but effectively ends up
being ~/.procmailrc]
Philip's rephrase seems to me to say the DROPPRIVS is effective here.
The specific "yes" answer seems to say the opposite, though that's
probably the imprecise wording of the question at fault, not the
answer. Does DROPPRIVS=yes do anything 2 INCLUDERC's below
/etc/procmailrc in this example?
This whole thing also raises some other questions, but I'll stick to
just those related to this issue. Rereading the procmail man page, I see
this is a misuse of /etc/procmailrcs/. I knew it's intended use was
different than mine, but didn't carefully consider the downside.
Intentional bad behavior is not a concern with my wife and kids. ;-)
But that still leaves unintentional screwups - maybe like this one. I do
explicitly set SHELL and PATH at the top of /etc/procmailrc. But my
guess is the rest of this stuff should be moved. So...
1. Would moving these files to somewhere other than /etc/procmailrcs be
sufficient, or is the whole notion of doing user specific processing
from /etc/procmailrc too broken to be rescued?
2. If it can be ok with the right implementation, and assuming
priviledges are dropped asap, could these rcfiles reside in a directory
below /etc/procmailrcs/ or must they be completely unrelated?
Thanks.
--
/"\
Don Hammond \ / ASCII Ribbon Campaign
Raleigh, NC US X Against HTML Mail,
/ \ and News Too
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail