On Tue, 22 Jun 2004 12:26:12 +0200
Matthias Andree wrote:
Sam Varshavchik <mrs...@courier-mta.com> writes:
...[snip]...
Sam,
the other thing is the group permissions.
Maildrop (setuid or run as root, in delivery mode) will set the
primary group ID, drop supplementary group IDs and finally will set
the user ID. This is no different from Postfix's local(8) delivery
service that David is also using: it, too, will strip supplementary
group IDs, hence tricks with group writable logs won't work here, at
least not for systems that put each user in their own group.
OTOH, giving users write permissions for logs may not be a good plan
either.
I can see two solutions without knowing off-hand if maildrop
implements either already:
1. offer to run a separate (and possibly restricted) configuration
file
BEFORE dropping privileges when setuid-root
2. offer to log into a command instead of a file. That might then be
setgid and be as simple as a read and a write.
Greetings Sam and Matthias,
I was thinking about this some more last night and realized that the
maildrop.log problem is the tip of an iceberg.
An important task of my MDA is to run a spam filter and copy messages
classified as spam to an archival folder and (finally) divert their
delivery (to the sysadmin). Both of these tasks call for writable files
or a privileged user.
Here's my idea of what would accomplish this:
Since /etc/maildroprc can only be changed by a privileged user, its
rules are "safe", hence maildrop can run with privileges while
processing this file. Upon reaching the end of /etc/maildroprc,
maildrop can change its userid and privilege level, read
$HOME/.mailfilter, and process the additional rules as the user.
Using privilege levels corresponding to the source (owner) of the rules
would allow processing, specifically spam processing and logging, such
as I presently have with procmail. The present mode of dropping
privilege early on puts major limits on maildrop's ability to do system
level operations.
What do you think? Any merit to the above ideas?
Regards,
David
18 messages in net.sourceforge.lists.courier-maildrop[maildropl] multiuser maildrop [was: ...
