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.
