Hi
I have a remaining issue with a mail server setup.
Composed of Postfix and Dovecot it is is a 'local' mail server
At first I relied upon Mysql to store the various parameters, and then
switched to a flat file approach
I also initially set the server up to handle virtual users, but then I
realized that it was destined to manage local system accounts only. So I
reconfigured it accordingly
Relying on system accounts for authentication means that the domain name
component is absent from the username (as opposed to virtual user
identifiers)
This caused me some difficulty at first with roundcube, but I was able
to get around it through a manual adjustment in Mysql
The remaining aspect that isn't working is the delivery of emails.
The entry in master.cf for dovecot looks looks this:
dovecot unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deli
ver -d ${recipient}
The problem is that the recipient equates to the users email address,
which can't in fact be used for authentication purposes with system
accounts.
I then tried replacing recipient with user:
dovecot unix - n n - - pipe
flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deliver -d ${user}
There seems to be a rights issue because I get the following error:
dovecot Fatal: setgid(100(users)) failed with euid=8(mail), gid=8(mail),
egid=8(mail): Operation not permitted
Any ideas ?
thanks
yann
# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-686 i686 Debian 6.0.7 ext4
log_timestamp: %d-%m-%Y %H:%M:%S
protocols: imap imaps pop3 pop3s
ssl_cert_file: /etc/ssl/certs/postfix.pem
ssl_key_file: /etc/ssl/private/postfix.key
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_privileged_group: mail
mail_location: maildir:/var/mail/%u
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
lda:
auth_socket_path: /var/run/dovecot/auth-master
postmaster_address: postmaster at holinice.com
mail_plugins: sieve
log_path:
syslog_facility: mail
auth default:
mechanisms: plain login
verbose: yes
passdb:
driver: pam
userdb:
driver: passwd
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 432
user: mail
group: mail
At 10PM +0200 on 28/05/13 you (Yann Shukor) wrote:> > The remaining aspect that isn't working is the delivery of emails. > > The entry in master.cf for dovecot looks looks this: > > dovecot unix - n n - - pipe > flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deli > ver -d ${recipient}[Just like someone who was posting a little while ago, your Dovecot binaries are under /usr/lib. This is very weird: they should really be under /usr/libexec...]> The problem is that the recipient equates to the users email address, > which can't in fact be used for authentication purposes with system > accounts.You can get around this problem with auth_username_format on the Dovecot side. On my system I have auth_username_format = %Lu which instructs Dovecot to look up users by the lowercased username part only. It's also best, when passing a recipient address to the LDA, to use -a rather than -d, since this will also strip off any +extension to the username (assuming you've configured Postfix and Dovecot to use the same extension character), while making it available to Sieve scripts later on.> I then tried replacing recipient with user: > > dovecot unix - n n - - pipe > flags=DRhu user=mail:mail argv=/usr/lib/dovecot/deliver -d ${user} > > There seems to be a rights issue because I get the following error: > > dovecot Fatal: setgid(100(users)) failed with euid=8(mail), gid=8(mail), > egid=8(mail): Operation not permittedThink a bit about what's going on here. Postfix is running deliver as user 'mail', and you're passing the -d argument, so deliver looks up that user in the userdb and tries to setuid and setgid to the uid and gid for that user. Since 'mail' is neither the target u/gid nor root, it is not allowed to do that. There are three basic strategies here. The first, and in some ways the simplest, is to forget you're using 'system users' and store all the mails under the 'mail' userid. This means you need to configure Dovecot just as you had for virtual users: in particular, the Dovecot userdb should return mail's u/gid for all users, and each user needs a 'Dovecot home directory' owned by 'mail'. (You can easily do this with the 'static' userdb, just as you would have for virtual users.) The advantage here is the simplicity. The disadvantages are: first, that users logged in to the mail server can't access their own mail spool directly but have to go through IMAP (probably not important, but this was the historical reason for doing deliveries as the delivered-to user); second, that if you have any OS-level filesystem quotas set up a user's mail will be counted against mail's quota rather than their own; and third, that there is a small chance a user might find some way to break Dovecot's 'imap' process and use it to read or modify other people's mail. The second, which is what I currently do, is to use Postfix's local(8) delivery agent, which runs as root and setuids down to the delivered-to user's uid before doing final delivery. You can get local(8) to deliver through Dovecot by setting Postfix's mailbox_command parameter: the important thing here is that when the LDA is invoked it already has the correct u/gid. With this method you keep the other features of local(8), like /etc/aliases and .forward files; this may be an advantage or a disadvantage depending on your setup. The third is to have the Dovcot delivery process running as root, so it can successfully setuid down to the user's credentials itself. Probably the easiest way to do this is to use the LMTP server (and Postfix's lmtp(8) transport rather than a dedicated Dovecot master.cf entry), though I would expect that if you simply changed that LDA entry to 'user=root:wheel' that the LDA would correctly setuid down to the user's credentials before doing any deliveries. This is what I would recommend for a new installation; the only reason I don't do this is because I upgraded from 1.2, which didn't have LMTP, and I haven't got round to migrating yet.> # 1.2.15: /etc/dovecot/dovecot.confOh Lord, you're still using 1.2... Don't do that. Use the latest 2.1. You can get Debian packages from http://wiki2.dovecot.org/PrebuiltBinaries . Ben
[Please keep replies on the list.] At 6AM +0200 on 29/05/13 you (Yann Shukor) wrote:> > Although simpler to set up, I chose to steer clear of the single user > representing 'all' because I liked the idea of giving users access to > Usermin allowing them to manage their own password and vacation msg > (+filtering, ...) and furthermore they could login with their username > (domain-less).While it's often convenient to make a distinction between 'system' and 'virtual' users, Dovecot doesn't actually know the difference. It just looks users up in the passdb and userdb you have configured. This means it's perfectly straightforward to do a completely 'virtual user' setup, and then change the passdb to 'pam', which will let the users log in with their ordinary Unix password. To allow users to log in with just a username, all you need to do is make sure the users in the userdb and passdb are listed that way. Userdb passwd and passdb pam naturally are, but there's nothing to stop you using other userdbs if you want to. The only trick here is that if you're using LDA/LMTP then incoming deliveries will (or, at least, usually should) be addressed to a full email address, so you need auth_username_format to trim that back to a username. I don't know anything about Usermin, but if it is trying to set up traditional procmail filtering and vacation(1), you may be in trouble. Or, at least, you may have to give up on using Dovecot to deliver the mail and let Postfix's local(8) and procmail deliver it into maildirs themselves. If you're happy with this, this isn't a problem for Dovecot, but it might be better to go with Sieve filtering instead. Sieve is a newish mail filtering language, designed primarily to be safe (procmail has a nasty habit of letting users run arbitrary programs). Dovecot's LDA has a pretty complete sieve implementation called Pigeonhole (you may need to install it separately), which also supports a protocol called ManageSieve designed for uploading sieve scripts remotely. There are plugins for some webmail systems (and some desktop mail clients, for that matter) which let the user edit their filters in a gooey way; this includes setting up vacation messages. I use Roundcube webmail for this purpose; it also has a perfectly good PAM password- changing plugin. Ben