paths and permissions
mailings02 at ttlexceeded.com
Fri Feb 27 23:10:10 EST 2004
Eric Wood <eric at interplas.com> wrote:
>> Bob George wrote:
>> I *SUPPOSE* it might mean that anything AFTER the DROPPRIVS
> That's got to be it. After all, you can change other
> variables anywhere throughout the recipe.
Yes, that's it. UP TO DROPPRIVS, procmail runs as root. When it's encountered,
it takes on the UID/GID of the user it's receiving mail on behalf of. You can
observe this when running procmail with the debug option.
> I suppose you can
> even use as many DROPPRIVS statements throughout the recipe as
> you wish.
Well, the FIRST will have effect, removing root privs and changing to those of
the user. It's a one-time, one-way switch to the best of my knowledge.
> "Behalf of the recipient".... to me this would mean that
> procmail would have to retreive the uid and gid of the
Yes, it knows this (or rather is called with this) information when called.
Gyepi's message summed up the mechanism pretty well, but in short, procmail is
called BY the user (that's "how it knows") but because of the SUID/SGID,
ASSUMES the uid/gid of root (based on ownership).
> Now, all my virtual domains and virtual users are
> handled in auxillary passwd/shadow files - not the system
> passwd/shadow file. UID's start at 60000 per vdomain as
> typical. procmail on my system is *not* setuid and is actually
> called under to uid of 60000 or whatever vuser. Thankfully,
> this effectively neutralizing procmail vulnerabilities. I
> just tested it and DROPPRIVS has no effect on me - again
> because of virtual users is the "recipient" in which procmail
> didn't have the brains to switch to.
Ah, at this point, PLEASE refer to procmail resources, or the procmail list.
There are caveats AGAINST using procmail for virtual domains, and specific
instructions on how to do so.
(Aside: One of the biggest problems with implementing anti-spam is jumping
between the various resources for procmail, formail, spamassassin, bogofilter,
clamav, amavis, mailfilter, anomy sanitizer and all the other wondrous
> And the arguement is full circle again - only my wordlist.db is
> Now, since my logs didn't complain about a missing user in
> /etc/passwd when DROPPRIVS was issued, that would mean the
> original uid (root) continued. We'll have to check the
> procmail code to see if the error is ignored which could be
> another security hole. -Eric Wood
A check is good, but it'd also be worth asking on the procmail list, as I've
seen these topics raised there as well. I AM NOT any sort of expert. I just so
happened to be looking at some of this info today.
More information about the Bogofilter