[Dovecot] Segfault when opening a public folder, dovecot 1.1 beta4

Adam McDougall mcdouga9 at egr.msu.edu
Sun Oct 28 21:37:56 EET 2007


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/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.

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.  


More information about the dovecot mailing list