I configured dovecot with Postfix with mysql
Now I have directory /home/mail/virtual
User/group postfix.postfix
I added one domain, and one user.
I login is successful but it gets interupted because of this.
pop3(xx@private-projects.net): Aug 11 00:48:53 Error: lstat(/home/mail/virtual/private-projects.net/xx@private-projects.net/cur) failed: Permission denied
pop3(xx@private-projects.net): Aug 11 00:48:53 Error: lstat(/home/mail/virtual/private-projects.net/xx@private-projects.net/cur) failed: Permission denied
pop3(xx@private-projects.net): Aug 11 00:48:53 Warning: I/O leak: 0x8050cc0 (0)
pop3(xx@private-projects.net): Aug 11 00:48:53 Warning: I/O leak: 0x8084e90 (1)
[root@octalys dovecot]# ls -la /home/mail/virtual/private-projects.net/xx\@private-projects.net/cur/
total 8
drwxrw---- 2 postfix postfix 4096 Aug 2 21:47 .
drwxrw---- 5 postfix postfix 4096 Aug 2 21:47 ..
[root@octalys dovecot]#
I added dovecot user to postfix group. I even tried chmod -R 777 * in virtual.
It doesn't work.
Whats the problem ?
On Wed, 2004-08-11 at 11:20 +0200, Alex wrote:
I added dovecot user to postfix group. I even tried chmod –R 777 * in virtual.
Dovecot user isn't used for accesing mails. I wrote a page about this in http://wiki.dovecot.org/moin.cgi/UserIds, please read and say if you didn't understand something.
The fix is anyway to put the right UID in the Mysql database.
Oh thanks for answering. I fixed it with a stupid mysql query... 'gid as 89, uid as 89' But your article is right, is better to give every user his own uid/gid. Will change it tomorrow.
-----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] Sent: Sunday, August 15, 2004 9:24 PM To: Alex Cc: dovecot@dovecot.org Subject: Re: [Dovecot] permission denied?
On Wed, 2004-08-11 at 11:20 +0200, Alex wrote:
I added dovecot user to postfix group. I even tried chmod -R 777 * in virtual.
Dovecot user isn't used for accesing mails. I wrote a page about this in http://wiki.dovecot.org/moin.cgi/UserIds, please read and say if you didn't understand something.
The fix is anyway to put the right UID in the Mysql database.
Timo Sirainen wrote:
I wrote a page about this in http://wiki.dovecot.org/moin.cgi/UserIds
Quoting from http://wiki.dovecot.org/moin.cgi/UserIds:
- Dovecot user dovecot user...is only used while Dovecot is processing user logins [...]
- Authentication process UID auth_user setting...only specifies the UID under which dovecot-auth process is run. ...you might want to create a separate dovecot-auth user to use here if you're not authenticating with PAM or shadow file which require roots.
This and other documentation seems to suggest that the 'dovecot' user ID shouldn't be reused as the auth_user setting. But based on how you have described the purpose of the two IDs, they appear to be serving a similar purpose, and thus it might make sense to use the same ID.
Could you clarify in the documentation whether this is an acceptable practice, or if not, why?
A scenario in which I could see there being an advantage is one in which the network process (running as 'dovecot') is compromised, and the hacker would then be unable to access the password database due to it providing access only to the UID specified by auth_user. Although it seems that additional security steps are really necessary in order for that to be true. In a typical SQL database setup, the database won't enforce system UID access restrictions, so it'll be up to the administrator to make sure the Dovecot database configuration file (say dovecot-mysql.conf) is not generally readable.
Which raises the question, how restrictive can permissions be on those configuration files? Are they read by Dovecot while root? Or will they be read by the authentication process while running as auth_user? If they can be readable only by root, and the administrator takes advantage of that, then it seems there would be little advantage for auth_user != login_user because any non-root account wouldn't be able to read the config file.
I see my dovecot-mysql.conf is world readable. Oops. Probably not a good thing, given it contains a MySQL password in clear text. You might want to put a security check into the code somewhere for that, in the same way it is common for MTAs to check on the permissions of files they depend on.
-Tom
On 16.8.2004, at 11:23, Tom Metro wrote:
This and other documentation seems to suggest that the 'dovecot' user ID shouldn't be reused as the auth_user setting. But based on how you have described the purpose of the two IDs, they appear to be serving a similar purpose, and thus it might make sense to use the same ID.
Could you clarify in the documentation whether this is an acceptable practice, or if not, why?
A scenario in which I could see there being an advantage is one in which the network process (running as 'dovecot') is compromised, and the hacker would then be unable to access the password database due to it providing access only to the UID specified by auth_user. Although it seems that additional security steps are really necessary in order for that to be true. In a typical SQL database setup, the database won't enforce system UID access restrictions, so it'll be up to the administrator to make sure the Dovecot database configuration file (say dovecot-mysql.conf) is not generally readable.
The point is more about making sure that the untrusted login process can't go directly poking into trusted processes. Having login processes be able to ptrace() the auth process would be the worst case, but luckily both login and auth processes are treated as setuid processes so it's not allowed. But if they were running with same UIDs it'd be at least possible to let login process kill auth process. Not very nice either. I want to keep login processes in as restricted sandbox as possible.
Which raises the question, how restrictive can permissions be on those configuration files? Are they read by Dovecot while root? Or will they be read by the authentication process while running as auth_user?
Looks like currently the config files are read as auth_user. I changed them now to be read before dropping privileges.
I see my dovecot-mysql.conf is world readable. Oops. Probably not a good thing, given it contains a MySQL password in clear text. You might want to put a security check into the code somewhere for that, in the same way it is common for MTAs to check on the permissions of files they depend on.
Hmm. I guess it could be useful.
BTW. I'm pretty lazy at updating documentation. I finally changed most of the things you mentioned, but I wouldn't have minded if you had just changed them directly in Wiki :)
Timo Sirainen wrote:
This and other documentation seems to suggest that the 'dovecot' user ID shouldn't be reused as the auth_user setting.
The point is more about making sure that the untrusted login process can't go directly poking into trusted processes. ... I want to keep login processes in as restricted sandbox as possible.
OK. Something that would be helpful would be a block diagram or table of the various Dovecot processes showing their purpose and privilege. Something like:
process: dovecot user: root purpose: parent process/master daemon
process: imap-login
user:
process: dovecot-auth
user:
process: imap-login
user:
process: imap user: (obtained from the user database) purpose: implements the IMAP protocol; interacts with the user's mailboxes
etc.
Which raises the question, how restrictive can permissions be on those configuration files? Are they read by Dovecot while root? Or will they be read by the authentication process while running as auth_user? I see my dovecot-mysql.conf is world readable. Oops. Probably not a good thing, given it contains a MySQL password in clear text.
Looks like currently the config files are read as auth_user. I changed them now to be read before dropping privileges.
Ah...I better tweak my permissions then. I had switched the MySQL config file to be readable only by root, and hadn't noticed any problems, but that's because my dovecot-auth hasn't been restarted since the change.
You might want to put a security check into the code somewhere for that, in the same way it is common for MTAs to check on the permissions of files they depend on.
Hmm. I guess it could be useful.
It could always be relegated to an external script if you'd prefer not to muddy up the code. Though that might require some duplication of effort, such as parsing the config files.
BTW. I'm pretty lazy at updating documentation. ...I wouldn't have minded if you had just changed them directly in Wiki :)
I considered that. After all, that's the point of using a Wiki. Though I figured it'd be a bit more polite to put the ideas out there for discussion before making the changes.
BTW, I have a Dovecot-MySQL howto about half done. I'll finish it up once I'm done with a Postfix project and have time to get back to it.
-Tom
participants (3)
-
Alex
-
Timo Sirainen
-
Tom Metro