[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20011014061611.A14794@openwall.com>
Date: Sun, 14 Oct 2001 06:16:11 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Postfix and procmail delivery ?
On Sat, Oct 13, 2001 at 01:38:21PM +0300, Jarno Huuskonen wrote:
Hi,
> AFAIK there's a small issue with using procmail as mailbox_command with
> postfix: postfix runs procmail as the user receiving mail and if the
> /var/spool/mail/user doesn't exist procmail(not suid/sgid) is unable to
> create the mailbox. (I only tested this very briefly on an Owl test
> install, but this at least is the case on RedHat (after procmail update)).
Yes. procmail delivery with Postfix isn't default, but is a supported
configuration on Owl. Currently, you have to ensure the mailboxes are
there if you choose to uncomment the main.cf line.
> Do you have any workaround for this ?
> I think Chris Wing (Caen Linux) has made a patch for useradd to create
> the user's mailbox. Something like this might be useful for those
> wishing to use procmail.
As Nergal has mentioned, there's going to be an updated shadow-utils
package "soon" which will do just that. I am delaying it for other
reasons (it primarily does a lot of other changes that require another
update first). BTW, this is almost exclusively Nergal's work. Stay
tuned. :-)
BTW, creating user mailboxes in useradd safely requires O_EXCL +
either fchmod/fchown or doing the open as the user. This is because
the directory is writable by group mail. Someone could want to check
Chris Wing's patch for this (I didn't).
Other approaches to solving the procmail problem include making it
SGID mail or patching Postfix to run it with group mail or even making
a copy of procmail in a restricted directory SGID mail and patching
Postfix to use a special group for accessing procmail for two layers
of security. These will also enable dot-locking to work (again). I
am accepting votes on this matter.
Of course, SGID procmail doesn't mean it is SGID and world-executable
by default. If this approach is chosen, I'll make this owl-control'able,
which will effectively declare that SGID procmail is now a supported
configuration. (Currently it isn't, in the sense that fixes for bugs
which affect it may not be committed into the stable branch.)
> Do you have any ideas on how to prevent users from seeing the postfix
> mailqueues / or flushing the queue (sendmail -q) ?
This has been on my Postfix TODO since the day I started integrating
it into Owl. But this item hasn't been completed yet. :-(
Restricting the queue runs will actually require a patch, I'm afraid.
So I'd want to update our Postfix to a recent version first.
If anyone is curious, here's what the TODO list looked like. Completed
items are marked with a plus sign.
+ sparse files
+ procmail w/o shell
+ postfix.init
+ chkconfig
+ no server by default
+ main.cf: aliases: no nis lookups
control: sgid vs. writable postdrop
+ control: local vs. server
control: native vs. procmail
+ default local nets: /32
+ dangerous /var/spool/postfix/* ownership
+ /etc/syslog.conf: -maillog
+ unprivileged delivery user
+ 3 users/groups to owl-etc
+ postdrop: 2755 -> 2711
+ /etc/aliases -> /etc/postfix/aliases && newaliases
+ /usr/lib/sendmail
+ review/edit default aliases file
+ chroot
restrict queue views
Last edited: January, 2001.
The "sgid vs. writable" I will probably drop, as I don't see any
advantage to writable mail spools for anyone at all. The remaining
two items, well, remain.
Then there're a few thoughts written down based on Postfix patches
I've seen after the integration.
I am going to get back to this stuff when updating the package.
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
