On Thu, 2011-02-10 at 21:26 +0100, Andrea Borghi wrote:
What i am trying to do is leaving all the dovecot services running in chroot mode (as they do) but let deliver running in NORMAL (non-chroot mode)
How is deliver even chrooting? Postfix doesn't call it chrooted and since it's user vmail:vmail the process isn't privileged to do any chrooting of its own.
Server with no local users except for root,
I enabled SUID bit on deliver binary, to get the thing going. but i doen't like that. It was only a rapid solution to get the system going while searching a more robust alternative.
OK, so it's deliver that does the chrooting.
I was reasoning that deliver is in a protected path, with antivirus et al before it so i can live with deliver not-chrooted, while i certainly desire the client-contacted modules (imap, pop3, etc) in their own jail.
But deliver doesn't call antivirus, right? So what's the problem of keeping deliver chrooted? There shouldn't be any need for any libraries or anything inside the chroot.
So you know a method to substitute TWO ldap values in the mail parameter definition?
Not possible currently.
so you're telling i have no other option except to fold over the two parts of the path directly in the LDAP database and reconfigure dovecot (as a whole) to map just one attribute?
Yeah.
I can certainly live with that but in this case i am loosing flexibility.
perhaps dovecot 2+ can do this (i confess i have not researched version2 yet) ? i certainly can move from the packetized debian version to a locally built one without much trouble.
I've some plans to rewrite LDAP configuration to support this and other things.