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

[Adam McDougall]

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.