[Dovecot] Maildir owner importance
I have set up a directory (/var/local/virtualdir/) as the maildir with a special user/group (virtualmail) and in it I create directories for each domain (example1.tld, example2.tld etc) and sub dir's for each mailbox). Only at the moment, apart from the first one, they are all created as with user root as the owner. How important is to have all the directory tree owned by the same user group (virtualmail:virtualmail) ?
How important is to have all the directory tree owned by the same user group (virtualmail:virtualmail) ?
My understanding (which could be wrong) is that it's pretty important.
First, as a rule of thumb, nothing should be owned by root that doesn't
have to be owned by root. When Dovecot is writing mail to a directory,
it assumes the user ID of the recipient. In your virtual setup you
probably don't have local users, so Dovecot will change to the user id
returned from your database/ldap query, or, if using LDAP and you want
to, to the user specified in user_global_uid setting. In either case,
that user should be the user who owns the directory tree (virtualmail)
and not root. Your setup can work, of course, if you give the
directory read/write permissions for group and world, but why would you
want to?
- Pete
OK, I'v set all the directory tree from the main maildir (/var/local/virtualdir/) to the virtualmail user using chmod -R virtualmail.virtualmail /var/local/virtualdir
And correct me if I'm wrong,
The auth_user is still "auth_user = root" and I need to have the
"default_mail_env"
set as default_mail_env = maildir:/var/local/virtualdir/%d/%n .
But I also need to set:
first_valid_uid = 100
last_valid_uid = 100
first_valid_gid = 101
last_valid_gid = 101
which are the uid and gid for the user virtualmail
On Mon, 27 Dec 2004 13:12:50 -0500, Peter Lacey placey@wanderingbarque.com wrote:
How important is to have all the directory tree owned by the same user group (virtualmail:virtualmail) ?
My understanding (which could be wrong) is that it's pretty important. First, as a rule of thumb, nothing should be owned by root that doesn't have to be owned by root. When Dovecot is writing mail to a directory, it assumes the user ID of the recipient. In your virtual setup you probably don't have local users, so Dovecot will change to the user id returned from your database/ldap query, or, if using LDAP and you want to, to the user specified in user_global_uid setting. In either case, that user should be the user who owns the directory tree (virtualmail) and not root. Your setup can work, of course, if you give the directory read/write permissions for group and world, but why would you want to?
- Pete
OK, I'v set all the directory tree from the main maildir (/var/local/virtualdir/) to the virtualmail user using chmod -R virtualmail.virtualmail /var/local/virtualdir
And correct me if I'm wrong, The auth_user is still "auth_user = root" and I need to have the "default_mail_env" set as default_mail_env = maildir:/var/local/virtualdir/%d/%n . But I also need to set: first_valid_uid = 100 last_valid_uid = 100 first_valid_gid = 101 last_valid_gid = 101 which are the uid and gid for the user virtualmail
The auth_user should _not_ be root. It should be set to a less privileged user, such as "dovecot." This user should not have a shell account. The dovecot user should have been created for you by the post-compilation install script (make install) or by the package installation. If it's not there, something like this should work on RedHat like systems:
/usr/sbin/groupadd -g [some unused group id less than 100] -r dovecot /usr/sbin/useradd -d /var/run/dovecot -s /bin/false -g dovecot -M -r -u [some user id less that 100] dovecot
The rest of your settings look good.
If you are looking for information on how to set up Dovecot with LDAP
and virtual users, I'll point you at my own HOWTO on the subject:
http://www.wanderingbarque.com/mailserver.html
- Pete
I'v changed the 'auth_user' to 'dovecot' and it have a uid/gid lower then 100. Does the the virtualmail user need to have a shell account ? Do I have to change the last_valid_uid/gid to the dovecot user or leave them on the virtualmail user ? Are there some settings in the dovecot.conf file that I need to check that they will not be there ?
The plan is to use Dovecot with pam&mysql. (Expect quextions soon).
On Tue, 28 Dec 2004 12:38:16 -0500, Peter Lacey placey@wanderingbarque.com wrote:
OK, I'v set all the directory tree from the main maildir (/var/local/virtualdir/) to the virtualmail user using chmod -R virtualmail.virtualmail /var/local/virtualdir
And correct me if I'm wrong, The auth_user is still "auth_user = root" and I need to have the "default_mail_env" set as default_mail_env = maildir:/var/local/virtualdir/%d/%n . But I also need to set: first_valid_uid = 100 last_valid_uid = 100 first_valid_gid = 101 last_valid_gid = 101 which are the uid and gid for the user virtualmail
The auth_user should _not_ be root. It should be set to a less privileged user, such as "dovecot." This user should not have a shell account. The dovecot user should have been created for you by the post-compilation install script (make install) or by the package installation. If it's not there, something like this should work on RedHat like systems:
/usr/sbin/groupadd -g [some unused group id less than 100] -r dovecot /usr/sbin/useradd -d /var/run/dovecot -s /bin/false -g dovecot -M -r -u [some user id less that 100] dovecot
The rest of your settings look good.
If you are looking for information on how to set up Dovecot with LDAP and virtual users, I'll point you at my own HOWTO on the subject: http://www.wanderingbarque.com/mailserver.html
- Pete
Does the the virtualmail user need to have a shell account ? Do I have to change the last_valid_uid/gid to the dovecot user or leave them on the virtualmail user ? No, and technically you don't even need a virtualmail user, just a uid and gid. So, for instance, you could do this (so long as you were certain that
On Tuesday 28 December 2004 23:40, Roi Efrati wrote: the numbers in question would never be used for a real user/group):
first_valid_uid = 5000 last_valid_uid = 5000 first_valid_gid = 5000 last_valid_gid = 5000
Then just 'chown 5000.5000 /var/local/virtualdir/' or wherever else you want to keep your maildir, and you're set. :Peter
On Wed, 2004-12-29 at 12:55 +0300, Peter Clark wrote:
Does the the virtualmail user need to have a shell account ? Do I have to change the last_valid_uid/gid to the dovecot user or leave them on the virtualmail user ? No, and technically you don't even need a virtualmail user, just a uid and gid. So, for instance, you could do this (so long as you were certain that
On Tuesday 28 December 2004 23:40, Roi Efrati wrote: the numbers in question would never be used for a real user/group):
first_valid_uid = 5000 last_valid_uid = 5000 first_valid_gid = 5000 last_valid_gid = 5000
first_valid_gid / last_valid_gid aren't really that important to change. They are only extra checks to prevent accidental use of eg. some daemon accounts due to unset passwords. So if you are using only virtual users and not /etc/passwd at all, it's rather useless to change them.
If you want to use 5000 UID, just make sure the userdb returns 5000 as UID.
And there was talk about auth_user in this thread too. The most important thing with it is that it must not be the same as login_user (1.0-tests enforce this check). Other than that, it's better to be the least privileged user that has access to passdb and userdb, but just using root isn't that bad either.
On Wed, 2004-12-29 at 13:06 +0200, Timo Sirainen wrote:
first_valid_gid / last_valid_gid aren't really that important to change. They are only extra checks to prevent accidental use of eg. some daemon accounts due to unset passwords. So if you are using only virtual users and not /etc/passwd at all, it's rather useless to change them.
first/last_valid_uid I mean. The first/last_valid_gid are even less useful. But sure, setting them can prevent some damage if dovecot-auth has a security hole.
On Dec 29, 2004, at 6:06 AM, Timo Sirainen wrote:
And there was talk about auth_user in this thread too. The most important thing with it is that it must not be the same as login_user
Okay, I didn't know this. So the imap-login process should run as
user1 (not "root", typically "dovecot") and dovecot-auth should run as
user2 (could be root, should be just privileged enough to access the
auth_userdb and auth_passdb, which in the case of LDAP is anyone).
Here's the question, why is it important that these two not be the same
user?
Pete
On 29.12.2004, at 16:45, Peter Lacey wrote:
On Dec 29, 2004, at 6:06 AM, Timo Sirainen wrote:
And there was talk about auth_user in this thread too. The most important thing with it is that it must not be the same as login_user
Okay, I didn't know this. So the imap-login process should run as user1 (not "root", typically "dovecot") and dovecot-auth should run as user2 (could be root, should be just privileged enough to access the auth_userdb and auth_passdb, which in the case of LDAP is anyone).
Here's the question, why is it important that these two not be the same user?
Well, it solves more of a theoretical problem with not-so-great importance, but Dovecot is full of that anyway :)
The point of the login processes is that they try to keep the rest of the system safe even if attacker is able to run any code in them. This is because they are chrooted into (almost) empty non-writable directory and they run as user which has no privileges to do anything.
If you run dovecot-auth as the same user as the login process, the attacker will at least be able to kill your auth process. Probably nothing else though, since OS treats it as setuid process. But there have before been many holes in OSes allowing access to setuid processes..
And the reason why I'm expecting login processes to be the most attacked process, is because it runs all the SSL code, and that's big and complex and probably still has (or will have) some security holes allowing arbitrary code execution..
On Wednesday 29 December 2004 14:06, Timo Sirainen wrote:
If you want to use 5000 UID, just make sure the userdb returns 5000 as UID. I'm using LDAP for authentification, so /etc/dovecot-ldap.conf has this: user_global_uid = 5000 user_global_gid = 5000 This is what you're referring to, right?
And there was talk about auth_user in this thread too. The most important thing with it is that it must not be the same as login_user (1.0-tests enforce this check). Other than that, it's better to be the least privileged user that has access to passdb and userdb, but just using root isn't that bad either. I didn't know that login_user and auth_user needed to be separate. I've been using dovecot for both. But does this matter, since I'm using LDAP, and the "dovecot" user for LDAP technically exists only in the LDAP database, and is separate from the "dovecot" system user. So if I understand things correctly, they are technically two separate entities, just with the same name. Right? :Peter
On 29.12.2004, at 20:53, Peter Clark wrote:
If you want to use 5000 UID, just make sure the userdb returns 5000 as UID. I'm using LDAP for authentification, so /etc/dovecot-ldap.conf has
On Wednesday 29 December 2004 14:06, Timo Sirainen wrote: this: user_global_uid = 5000 user_global_gid = 5000 This is what you're referring to, right?
Either that, or return uid and gid fields from LDAP. But if they're the same, it doesn't matter.
And there was talk about auth_user in this thread too. The most important thing with it is that it must not be the same as login_user (1.0-tests enforce this check). Other than that, it's better to be the least privileged user that has access to passdb and userdb, but just using root isn't that bad either. I didn't know that login_user and auth_user needed to be separate. I've been using dovecot for both. But does this matter, since I'm using LDAP, and the "dovecot" user for LDAP technically exists only in the LDAP database, and is separate from the "dovecot" system user. So if I understand things correctly, they are technically two separate entities, just with the same name. Right?
If there is a dovecot user in LDAP it's not used for anything (except if it has password you could log in as dovecot to read its mails). auth_user and login_user both refer to system users.
participants (4)
-
Peter Clark
-
Peter Lacey
-
Roi Efrati
-
Timo Sirainen