Solution for: "macOS, Dovecot and setgroups() failed: Too many extra groups"

I upgraded my home server to macOS 10.14 after the upgrade on my laptop went very smooth. Also here the upgrade went smooth, but in the evening I discovered that I did not get any new email.

I started investigating. First I saw that Dovecot did not correctly start because an very old pid file said it has pid 104 and indeed there was a process wit pid 104, so dovecot though that is itself and stopped.

After removing the pid file and restarting Dovecot, it started again and correctly listened on port 993 (imaps). But the imap client still could not login.

Dovecot.log showed a lot of messages

Oct 11 08:10:27 imap(hwr)<12659>: Fatal: setgroups(501) failed: Too many extra groups

Reading the manpage for setgroups() revealed that this call fails when more than NGROUP_MAX (=16) groups are passed. And indeed the user has more than 16 groups:

$ id -G hwr
20 6 12 61 80 98 500 701 702 30 33 100 204 250 395 103 104

Looking at them shows a lot of groups that macOS creates and assigns internally and which one can't (easily) delete

$ id hwr
...
701(com.apple.sharepoint.group.1),702(com.apple.sharepoint.group.2),30(_keytabusers),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),103(com.apple.access_screensharing-disabled),104(com.apple.access_ssh-disabled)

I wrote to the dovecot mailing list and after an email exchange it turned out that there is a config option already present that can help here to reduce the number of groups passed to setgroups().

So the solution for me is to last_valid_gid = 100 in /usr/local/etc/dovecot/conf.d/10-mail.conf and restart Dovecot.

And now it is again humming along nicely :)

MikroTik: access control helpers

I have a MikroTik router and am overall pretty happy with it. Especially the Caps-Man feature for central administration of Wifi access points is great.

One thing I am a bit fighting with is restricting my kids from accessing the internet at certain times of the day. The firewall offers quite some features, but I can't get it to cut existing connections when the rule is triggered by time (and this is also true for the dynamic rules of the kid control feature). But then perhaps I just don't understand routeros well enough.

What I have done is to set up access-lists for caps-man. When they are enabled, WiFi access is no longer possible. They kick in well at the right time, so all is good.

But: sometimes my kids get legitimate exceptions and when I then forget to re-enable the rule, they won't tell me :)

What I have done is created the following script, which is nightly triggered from the scheduler:

:local maccaps
:foreach i in=[/caps-man access-list find ] do={
  :set maccaps ( [/caps-man access-list get value-name=comment number=$i])
  :if ($maccaps~ "^RESET .*\$") do={
       /caps-man access-list enable numbers=$i
    }
}

This looks for access list entries with a comment, where the comment starts with "RESET ". If found the script just re-enables that access list rule.

Permissions needed are read, write and policy.

Please let me know if there are better options.