[Dovecot] Segfault when opening a public folder, dovecot 1.1 beta4
I was trying to debug this with gdb, but I'm not sure how to make env MAIL=maildir:~/Maildir MAIL_PLUGINS=acl ACL=vfile gdb /tmp/imap understand the #shared/decs namespace from below so I can SELECT it.
I have a number of maildirs under #ahared/decs, I tried opening at least 2 of them but dovecot gives sig 11 without a direct error about the problem. I don't think this was exactly the same problem in 1.1b3, but unfortunately I deleted all the patches I was testing with so it would be a pain to test the same situation with 1.1b3 again (although if needed, I can).
If dovecot-shared exists in the folder I try to open, dovecot says: Oct 27 12:57:38 gribble dovecot: IMAP(mcdouga9): fchown() failed with file /home/mcdouga9/Maildir/dovecot11testing/public/indexes/decs/.unixadmin/dovecot.index.log: Operation not permitted Oct 27 12:57:38 gribble dovecot: child 55470 (imap) killed with signal 11
I am used to getting the first message because dovecot tries to apply perms from dovecot-shared to the index files which are elsewhere.
If I open a public folder without dovecot-shared, I see no contents but it does not sig11.
I am NOT using the acl plugin right now, it didn't seem to make a difference if it was loaded. When I left off with the dovecot 1.1b3 + 8 patches, I believe I was getting an assertion.
Please let me know if I goofed up something, I have a strange feeling about that here, or if you need more info. I'd like to go ahead and get a gdb trace.
# 1.1.beta4: /usr/local/etc/dovecot.conf ssl_cert_file: /usr/local/etc/apache2/ssl/cert.pem ssl_key_file: /usr/local/etc/apache2/ssl/cert.pem disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login verbose_proctitle: yes first_valid_uid: 1000 first_valid_gid: 0 mail_location: maildir:%h/Maildir:CONTROL=%h/Maildir/dovecot11testing/private/control:INDEX=%h/Maildir/dovecot11testing/private/indexes mail_debug: yes mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes mail_log_max_lines_per_sec: 0 imap_client_workarounds: delay-newmail netscape-eoh tb-extra-mailbox-sep namespace: type: public separator: / prefix: #shared/decs/ location: maildir:/egr/mail/shared/decs:CONTROL=%h/Maildir/dovecot11testing/public/control/decs:INDEX=%h/Maildir/dovecot11testing/public/indexes/decs list: yes subscriptions: yes namespace: type: private separator: / prefix: mail/ location: maildir:%h/Maildir:CONTROL=%h/Maildir/dovecot11testing/private/control:INDEX=%h/Maildir/dovecot11testing/private/indexes hidden: yes subscriptions: yes namespace: type: private separator: / inbox: yes list: yes subscriptions: yes auth default: mechanisms: plain login passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 384 user: postfix group: postfix plugin: acl: vfile:/usr/local/etc/dovecot-acls
On Sat, 2007-10-27 at 13:02 -0400, Adam McDougall wrote:
I was trying to debug this with gdb, but I'm not sure how to make env MAIL=maildir:~/Maildir MAIL_PLUGINS=acl ACL=vfile gdb /tmp/imap understand the #shared/decs namespace from below so I can SELECT it.
Easiest way to figure these kind of things is to set mail_executable=/tmp/dump.sh which contains:
#!/bin/sh set > /tmp/dovecot.env
And run dovecot --exec-mail imap. Then either use that information or just run ". /tmp/dovecot.env" before gdb imap.
If dovecot-shared exists in the folder I try to open, dovecot says: Oct 27 12:57:38 gribble dovecot: IMAP(mcdouga9): fchown() failed with file /home/mcdouga9/Maildir/dovecot11testing/public/indexes/decs/.unixadmin/dovecot.index.log: Operation not permitted Oct 27 12:57:38 gribble dovecot: child 55470 (imap) killed with signal 11
Fixed the crash: http://hg.dovecot.org/dovecot/rev/7373240c3d1d
But the real problem is that dovecot-shared file is owned by a group that your imap process doesn't belong to. You probably want to add it to mail_extra_groups.
On Sat, Oct 27, 2007 at 08:21:54PM +0300, Timo Sirainen wrote:
On Sat, 2007-10-27 at 13:02 -0400, Adam McDougall wrote:
I was trying to debug this with gdb, but I'm not sure how to make env MAIL=maildir:~/Maildir MAIL_PLUGINS=acl ACL=vfile gdb /tmp/imap understand the #shared/decs namespace from below so I can SELECT it.
Easiest way to figure these kind of things is to set mail_executable=/tmp/dump.sh which contains:
#!/bin/sh set > /tmp/dovecot.env
And run dovecot --exec-mail imap. Then either use that information or just run ". /tmp/dovecot.env" before gdb imap.
Thanks, I'll use it next time
If dovecot-shared exists in the folder I try to open, dovecot says: Oct 27 12:57:38 gribble dovecot: IMAP(mcdouga9): fchown() failed with file /home/mcdouga9/Maildir/dovecot11testing/public/indexes/decs/.unixadmin/dovecot.index.log: Operation not permitted Oct 27 12:57:38 gribble dovecot: child 55470 (imap) killed with signal 11
Fixed the crash: http://hg.dovecot.org/dovecot/rev/7373240c3d1d
Agreed
But the real problem is that dovecot-shared file is owned by a group that your imap process doesn't belong to. You probably want to add it to mail_extra_groups.
I want to avoid adding a group to any user that logs in because some of them are in many groups already and it might push them over the limit that FreeBSD allows, then they cannot login at all. With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these fchown errors and I was thinking of muting them so they do not fill my log, since they are harmless in my setup. Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
On 27.10.2007, at 21.51, Adam McDougall wrote:
But the real problem is that dovecot-shared file is owned by a group that your imap process doesn't belong to. You probably want to
add it to mail_extra_groups.I want to avoid adding a group to any user that logs in because
some of them are in many groups already and it might push them over the limit
that FreeBSD allows, then they cannot login at all.
If you don't need the other groups in Dovecot you can get rid of them
and just have the process use the user's primary group and
mail_extra_groups. I think this should work:
userdb passwd { args = system_user= }
With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these
fchown errors and I was thinking of muting them so they do not fill my log, since
they are harmless in my setup.
If these errors happen for index files Dovecot currently fallbacks to
using in-memory indexes.
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world- readable at least (currently actually mode 666). As long as the indexes are
accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52c
On Sat, Oct 27, 2007 at 10:13:46PM +0300, Timo Sirainen wrote:
On 27.10.2007, at 21.51, Adam McDougall wrote:
But the real problem is that dovecot-shared file is owned by a group that your imap process doesn't belong to. You probably want to add it to mail_extra_groups.
I want to avoid adding a group to any user that logs in because some of them are in many groups already and it might push them over the limit that FreeBSD allows, then they cannot login at all.
If you don't need the other groups in Dovecot you can get rid of them and just have the process use the user's primary group and mail_extra_groups. I think this should work:
userdb passwd { args = system_user= }
Actually, yes I like this alot and put this change into production. I was planning on using some secondary groups to prevent filesystem access, but I can accomplish the same protection easier with this and mail_extra_groups. Thanks! I didn't test yet that the secondary groups aren't loaded but I will sometime.
With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these fchown errors and I was thinking of muting them so they do not fill my log, since they are harmless in my setup.
If these errors happen for index files Dovecot currently fallbacks to using in-memory indexes.
Oh. Ugh. That might explain why the indexes don't always seem to load. For some reason I thought dovecot might print a message when it falls back to in-memory indexes; would that be possible?
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52c
I will roll that in and test alongside the next patch you sent. Thanks.
If you don't need the other groups in Dovecot you can get rid of them and
just have the process use the user's primary group and mail_extra_groups. I
think this should work:
userdb passwd {
args = system_user=
}Actually, yes I like this alot and put this change into production. I was planning on using some secondary groups to prevent filesystem access, but I can accomplish the same protection easier with this and mail_extra_groups. Thanks! I didn't test yet that the secondary groups aren't loaded but I will sometime.
According to my logs, it seems it does not prevent the secondary groups. I'd look at the code to see how it works, but I have to switch tasks and may not work more with dovecot until tomorrow. I suppose if I cannot get this to work, it sounds like I may be able to depend on the patch below.
With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these fchown errors and I was thinking of muting them so they do not fill my log, since they are harmless in my setup.
If these errors happen for index files Dovecot currently fallbacks to using
in-memory indexes.Oh. Ugh. That might explain why the indexes don't always seem to load. For some reason I thought dovecot might print a message when it falls back to in-memory indexes; would that be possible?
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52cI will roll that in and test alongside the next patch you sent. Thanks.
On Sat, 2007-10-27 at 17:42 -0400, Adam McDougall wrote:
If you don't need the other groups in Dovecot you can get rid of them and just have the process use the user's primary group and mail_extra_groups. I think this should work:
userdb passwd { args = system_user= }Actually, yes I like this alot and put this change into production. I was planning on using some secondary groups to prevent filesystem access, but I can accomplish the same protection easier with this and mail_extra_groups. Thanks! I didn't test yet that the secondary groups aren't loaded but I will sometime.
According to my logs, it seems it does not prevent the secondary groups. I'd look at the code to see how it works, but I have to switch tasks and may not work more with dovecot until tomorrow. I suppose if I cannot get this to work, it sounds like I may be able to depend on the patch below.
Looks like it overrides the system_user with empty value and Dovecot ends up calling initgroups(""). I'm not sure what that does, if anything. This fixes it: http://hg.dovecot.org/dovecot/rev/7f2501b3e993
With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these fchown errors and I was thinking of muting them so they do not fill my log, since they are harmless in my setup.
If these errors happen for index files Dovecot currently fallbacks to using in-memory indexes.Oh. Ugh. That might explain why the indexes don't always seem to load. For some reason I thought dovecot might print a message when it falls back to in-memory indexes; would that be possible?
Possible yes, but I'm not sure if it's a good idea. Users with filesystem quotas probably wouldn't want to see them. It's anyway done silently only when write fails because of ENOSPC/EDQUOT, in other cases some error is always logged.
On Sun, Oct 28, 2007 at 02:06:49AM +0300, Timo Sirainen wrote:
On Sat, 2007-10-27 at 17:42 -0400, Adam McDougall wrote:
If you don't need the other groups in Dovecot you can get rid of them and just have the process use the user's primary group and mail_extra_groups. I think this should work:
userdb passwd { args = system_user= }Actually, yes I like this alot and put this change into production. I was planning on using some secondary groups to prevent filesystem access, but I can accomplish the same protection easier with this and mail_extra_groups. Thanks! I didn't test yet that the secondary groups aren't loaded but I will sometime.
According to my logs, it seems it does not prevent the secondary groups. I'd look at the code to see how it works, but I have to switch tasks and may not work more with dovecot until tomorrow. I suppose if I cannot get this to work, it sounds like I may be able to depend on the patch below.
Looks like it overrides the system_user with empty value and Dovecot ends up calling initgroups(""). I'm not sure what that does, if anything. This fixes it: http://hg.dovecot.org/dovecot/rev/7f2501b3e993
Upon some further testing, this patch doesn't seem to do anything, because for some reason 1.1 allows me to login when I am in too many groups, but 1.0 fails (this is where I saw the errors), and both versions seem to act the same with or without the patch. When I use mail_executable to run a shell script to report group membership, on both servers I still see the full list when using system_user= and mail_extra_groups but I don't see the group I set in mail_extra_groups. I'm not sure what to think, is there a good place to stick in some debugging?
With some recent permission changes I've done (affects dovecot 1.0 as well), I get a good amount of these fchown errors and I was thinking of muting them so they do not fill my log, since they are harmless in my setup.
If these errors happen for index files Dovecot currently fallbacks to using in-memory indexes.Oh. Ugh. That might explain why the indexes don't always seem to load. For some reason I thought dovecot might print a message when it falls back to in-memory indexes; would that be possible?
Possible yes, but I'm not sure if it's a good idea. Users with filesystem quotas probably wouldn't want to see them. It's anyway done silently only when write fails because of ENOSPC/EDQUOT, in other cases some error is always logged.
On Sun, 2007-10-28 at 09:25 -0400, Adam McDougall wrote:
userdb passwd { args = system_user= }
This works only with v1.1. v1.0 just ignores it.
Looks like it overrides the system_user with empty value and Dovecot ends up calling initgroups(""). I'm not sure what that does, if anything. This fixes it: http://hg.dovecot.org/dovecot/rev/7f2501b3e993
Upon some further testing, this patch doesn't seem to do anything, because for some reason 1.1 allows me to login when I am in too many groups, but 1.0 fails (this is where I saw the errors), and both versions seem to act the same with or without the patch. When I use mail_executable to run a shell script to report group membership, on both servers I still see the full list when using system_user= and mail_extra_groups but I don't see the group I set in mail_extra_groups. I'm not sure what to think, is there a good place to stick in some debugging?
Have you set mail_drop_priv_before_exec=yes? If not, it should still be running as root in your mail_executable. If it's "no", I'm not really sure..
auth_debug=yes at least shows what auth process sends to master. It should show empty system_user.
On Sun, Oct 28, 2007 at 03:57:22PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 09:25 -0400, Adam McDougall wrote:
userdb passwd { args = system_user= }
This works only with v1.1. v1.0 just ignores it.
Hmm. I might be able to get by without this.
Looks like it overrides the system_user with empty value and Dovecot ends up calling initgroups(""). I'm not sure what that does, if anything. This fixes it: http://hg.dovecot.org/dovecot/rev/7f2501b3e993
Upon some further testing, this patch doesn't seem to do anything, because for some reason 1.1 allows me to login when I am in too many groups, but 1.0 fails (this is where I saw the errors), and both versions seem to act the same with or without the patch. When I use mail_executable to run a shell script to report group membership, on both servers I still see the full list when using system_user= and mail_extra_groups but I don't see the group I set in mail_extra_groups. I'm not sure what to think, is there a good place to stick in some debugging?
Have you set mail_drop_priv_before_exec=yes? If not, it should still be running as root in your mail_executable. If it's "no", I'm not really sure..
I have not changed it ever, dovecot -n does not report it.
auth_debug=yes at least shows what auth process sends to master. It should show empty system_user.
On Sat, Oct 27, 2007 at 03:52:28PM -0400, Adam McDougall wrote:
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52cI will roll that in and test alongside the next patch you sent. Thanks.
I'm not sure this is working completely, it seems to help but I still notice some errors. I made sure the mount was remounted without nosuid but on second thought I don't think that actually matters since we are not executing dovecot-shared.
I set sgid on all of my dovecot-shared files: -rw-rwSrw- 1 postlocal postlocal 0 May 15 17:30 /egr/mail/shared/decs/.receipts.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 May 15 17:30 /egr/mail/shared/decs/.support.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 12 11:03 /egr/mail/shared/decs/.jbossadmin.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Jun 25 15:52 /egr/mail/shared/decs/.network.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 May 15 17:30 /egr/mail/shared/decs/.postmaster.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 May 15 17:30 /egr/mail/shared/decs/.security.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 24 23:26 /egr/mail/shared/decs/.unixadmin.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 24 23:26 /egr/mail/shared/decs/.unixadmin.In-2007-10/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:46 /egr/mail/shared/decs/.unixadmin/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 24 21:48 /egr/mail/shared/decs/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:48 /egr/mail/shared/decs/.linuxadmin.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:48 /egr/mail/shared/decs/.linuxadmin/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:45 /egr/mail/shared/decs/.linuxadmin.In-2007-10/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:51 /egr/mail/shared/decs/.backups.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:51 /egr/mail/shared/decs/.backups/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:51 /egr/mail/shared/decs/.backups.In-2007-10/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:51 /egr/mail/shared/decs/.printmaster.In-2007-10/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:51 /egr/mail/shared/decs/.printmaster/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 25 00:52 /egr/mail/shared/decs/.printmaster.In/dovecot-shared -rw-rwSrw- 1 postlocal postlocal 0 Oct 24 23:26 /egr/mail/shared/decs/.unixadmin.Spam/dovecot-shared
Oct 28 09:58:59 gribble dovecot: IMAP(mcdouga9): fchown(/home/mcdouga9/Maildir/dovecot11testing/public/control/decs/.postmaster.In/dovecot-keywords.lock) failed: Operation not permitted
Other errors:
Oct 28 09:48:12 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.73172.4c26d7ffde1d024c) failed: Operation not permitted Oct 28 09:52:49 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.73230.fba3c6533356d144) failed: Operation not permitted Oct 28 09:53:00 gribble dovecot: IMAP(mcdouga9): fchown(/home/mcdouga9/Maildir/dovecot11testing/public/control/decs/.postmaster.In/dovecot-keywords.lock) failed: Operation not permitted Oct 28 09:53:00 gribble dovecot: IMAP(mcdouga9): fchown(/home/mcdouga9/Maildir/dovecot11testing/public/control/decs/.postmaster.In/dovecot-uidlist.tmp) failed: Operation not permitted Oct 28 09:58:25 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.73350.d3836dd2d12c3731) failed: Operation not permitted
On Sun, 2007-10-28 at 10:08 -0400, Adam McDougall wrote:
On Sat, Oct 27, 2007 at 03:52:28PM -0400, Adam McDougall wrote:
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52cI will roll that in and test alongside the next patch you sent. Thanks.
I'm not sure this is working completely, it seems to help but I still notice some errors. I made sure the mount was remounted without nosuid but on second thought I don't think that actually matters since we are not executing dovecot-shared.
I didn't notice that changed it only for index files. This should really make it work:
On Sun, Oct 28, 2007 at 04:54:12PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 10:08 -0400, Adam McDougall wrote:
On Sat, Oct 27, 2007 at 03:52:28PM -0400, Adam McDougall wrote:
Right now in my public folder permission scheme, the only thing I need dovecot-shared for (I think) is making client-added emails world-readable at least (currently actually mode 666). As long as the indexes are accessible by the user, I don't care what mode or group they are.
How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52cI will roll that in and test alongside the next patch you sent. Thanks.
I'm not sure this is working completely, it seems to help but I still notice some errors. I made sure the mount was remounted without nosuid but on second thought I don't think that actually matters since we are not executing dovecot-shared.
I didn't notice that changed it only for index files. This should really make it work:
http://hg.dovecot.org/dovecot/rev/b2c14c07dcb2
Applied to 1.1, I'll see how it goes.
However I just logged in with it and saw one I've been seeing occasionally:
Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d) failed: Operation not permitted
From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
On Sun, Oct 28, 2007 at 11:06:01AM -0400, Adam McDougall wrote:
On Sun, Oct 28, 2007 at 04:54:12PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 10:08 -0400, Adam McDougall wrote:
> On Sat, Oct 27, 2007 at 03:52:28PM -0400, Adam McDougall wrote:
>
> >> Right now in my public folder permission scheme, the only thing I need
> >> dovecot-shared for (I think) is making client-added emails world-readable
> >> at least
> >> (currently actually mode 666). As long as the indexes are accessible by
> >> the user,
> >> I don't care what mode or group they are.
>
> How about this: http://hg.dovecot.org/dovecot/rev/0dd9b91fd52c
>
> I will roll that in and test alongside the next patch you sent. Thanks.
>
> I'm not sure this is working completely, it seems to help but I still notice
> some errors. I made sure the mount was remounted without nosuid but on second
> thought I don't think that actually matters since we are not executing dovecot-shared.
I didn't notice that changed it only for index files. This should really
make it work:
http://hg.dovecot.org/dovecot/rev/b2c14c07dcb2Applied to 1.1, I'll see how it goes.
However I just logged in with it and saw one I've been seeing occasionally:
Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d) failed: Operation not permitted
From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
I did some hunting because I was curious (I assume you would know right away) and its from lib/safe-mkstemp.c which dotlock uses. In dovecot 1.1, whatever dotlock used doesn't look like it used fchown at all. I was wondering if fchown here in 1.1 has to do with NFS access cache flushing. I don't even understand why it is failing, its hard to inspect when its happening on a randomly named temporary file of course.
I also backported http://hg.dovecot.org/dovecot/rev/0dd9b91fd52c and http://hg.dovecot.org/dovecot/rev/b2c14c07dcb2 to my 1.0 semi-production server, and so far I have not seen a single fchown error from it yet. I used to get one on almost every folder access. yay! Thanks for this feature :)
I think right now alot of the problems I had with dovecot 1.1 have been patched, and other than the temp file error above I can forsee myself putting 1.1 into testing real soon by other users. Its looking pretty good.
On Sun, 2007-10-28 at 15:37 -0400, Adam McDougall wrote:
Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d) failed: Operation not permitted
From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
I did some hunting because I was curious (I assume you would know right away) and its from lib/safe-mkstemp.c which dotlock uses.
It's used for creating dovecot-acl-list. Hmm. Looks like there are now two places where Dovecot takes permissions from: dovecot-shared file and the directory where it exists. If you set g+s to the dir too this error goes away. I'll have to think a bit more what I'll do about this. Maybe dovecot-shared file just could go away and only the dir permissions would be used.
On Mon, Oct 29, 2007 at 10:49:34PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 15:37 -0400, Adam McDougall wrote:
Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d) failed: Operation not permitted
From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
I did some hunting because I was curious (I assume you would know right away) and its from lib/safe-mkstemp.c which dotlock uses.
It's used for creating dovecot-acl-list. Hmm. Looks like there are now two places where Dovecot takes permissions from: dovecot-shared file and the directory where it exists. If you set g+s to the dir too this error goes away. I'll have to think a bit more what I'll do about this. Maybe dovecot-shared file just could go away and only the dir permissions would be used.
That reminds me, I do think I put dovecot-shared in that directory just to satisfy 1.1. The group owner on /egr/mail/shared/decs/ is the group I am using to restrict entry into the directory (it is mode 770) so all of the users using folders inside are part of the group, so I'm not sure why the fchown would fail?
Also just a note (if I remember correctly) the existance of dovecot-shared causes dovecot+acl to treat the folder flags as private unless the code is modified (I still use that hack locally) so its not just the permissions of an object (presently dovecot-shared) that have an affect. Its seems like this is alot of functionality to load onto just the existance and permissions of a file :)
I did set g+s on /egr/mail/shared/decs/ and relogged in with thunderbird but got the error right away:
Oct 29 17:02:55 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.65681.2a5ad23c6e8cd308) failed: Operation not permitted
On Mon, Oct 29, 2007 at 05:10:44PM -0400, Adam McDougall wrote:
On Mon, Oct 29, 2007 at 10:49:34PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 15:37 -0400, Adam McDougall wrote:
> Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d)
> failed: Operation not permitted
>
> >From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
>
> I did some hunting because I was curious (I assume you would know right away) and its from
> lib/safe-mkstemp.c which dotlock uses.
It's used for creating dovecot-acl-list. Hmm. Looks like there are now
two places where Dovecot takes permissions from: dovecot-shared file and
the directory where it exists. If you set g+s to the dir too this error
goes away. I'll have to think a bit more what I'll do about this. Maybe
dovecot-shared file just could go away and only the dir permissions
would be used.That reminds me, I do think I put dovecot-shared in that directory just to satisfy 1.1. The group owner on /egr/mail/shared/decs/ is the group I am using to restrict entry into the directory (it is mode 770) so all of the users using folders inside are part of the group, so I'm not sure why the fchown would fail?
Also just a note (if I remember correctly) the existance of dovecot-shared causes dovecot+acl to treat the folder flags as private unless the code is modified (I still use that hack locally) so its not just the permissions of an object (presently dovecot-shared) that have an affect. Its seems like this is alot of functionality to load onto just the existance and permissions of a file :)
I did set g+s on /egr/mail/shared/decs/ and relogged in with thunderbird but got the error right away:
Oct 29 17:02:55 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.65681.2a5ad23c6e8cd308) failed: Operation not permitted
Lately I have been getting:
Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied
Right now I have /egr/mail/shared/decs/ unwritable to users. Some of these errors still happen when the directory is writable, but I am also concerned if it will cause these temp files to be renamed to dovecot-acl-list, which I assume would conflict with other users if created by one user.
Should I worry about these errors? Does it impair caching of folder lists or something? Thanks.
On Sat, Nov 17, 2007 at 12:14:37PM -0500, Adam McDougall wrote:
On Mon, Oct 29, 2007 at 05:10:44PM -0400, Adam McDougall wrote:
On Mon, Oct 29, 2007 at 10:49:34PM +0200, Timo Sirainen wrote:
On Sun, 2007-10-28 at 15:37 -0400, Adam McDougall wrote:
> Oct 28 11:01:40 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.97159.dc6633e16f47011d)
> failed: Operation not permitted
>
> >From the name, I can't even tell what its for, what dovecot-shared might be causing it, etc.
>
> I did some hunting because I was curious (I assume you would know right away) and its from
> lib/safe-mkstemp.c which dotlock uses.
It's used for creating dovecot-acl-list. Hmm. Looks like there are now
two places where Dovecot takes permissions from: dovecot-shared file and
the directory where it exists. If you set g+s to the dir too this error
goes away. I'll have to think a bit more what I'll do about this. Maybe
dovecot-shared file just could go away and only the dir permissions
would be used.
That reminds me, I do think I put dovecot-shared in that directory just to satisfy 1.1.
The group owner on /egr/mail/shared/decs/ is the group I am using to restrict entry into
the directory (it is mode 770) so all of the users using folders inside are part of the
group, so I'm not sure why the fchown would fail?
Also just a note (if I remember correctly) the existance of dovecot-shared causes
dovecot+acl to treat the folder flags as private unless the code is modified (I still use
that hack locally) so its not just the permissions of an object (presently dovecot-shared)
that have an affect. Its seems like this is alot of functionality to load onto just the
existance and permissions of a file :)
I did set g+s on /egr/mail/shared/decs/ and relogged in with thunderbird but got the
error right away:
Oct 29 17:02:55 gribble dovecot: IMAP(mcdouga9): fchown(/egr/mail/shared/decs/temp.gribble.65681.2a5ad23c6e8cd308)
failed: Operation not permittedLately I have been getting:
Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied
Right now I have /egr/mail/shared/decs/ unwritable to users. Some of these errors still happen when the directory is writable, but I am also concerned if it will cause these temp files to be renamed to dovecot-acl-list, which I assume would conflict with other users if created by one user.
Uhh, forget that part about being read only. I forgot it needs write so my shared deliver script can create new mailboxes.
Should I worry about these errors? Does it impair caching of folder lists or something? Thanks.
On Sat, 2007-11-17 at 12:14 -0500, Adam McDougall wrote:
Lately I have been getting:
Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:24:36 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.6d06d40810d76654) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): open(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied Nov 17 08:25:18 hill dovecot: IMAP(mcdouga9): safe_mkstemp(/egr/mail/shared/decs/temp.hill.80542.1f3d606a7fa4a3cc) failed: Permission denied
Are these still a problem?
participants (2)
-
Adam McDougall
-
Timo Sirainen