site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Honestly, I don't know. Have you tried asking the mail server team? -- Terry Kristan You can't do that, and you should not be trying. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This is because I don't know what configuration options, etc., are used in a default deployment. Dovecot allows a lot of them, including running all the users under a single system UID and doing access enforcement via connection credentials, and its ACL and preferred quota implementations don't fall through to native kernel enforcement, so it's entirely possible that it maintains its own account database separate from the system account database. If so, the problem you ran into would never come up because it would never be messing around with local system credentials at all. FWIW, this is the configuration I would have picked because of connection scaling for clients that like a connection per mailbox and ignore request/response tags, like the old OutLook; it doesn't make sense to have a process per connection or a process per client, if you want to support as many clients as you can. On Sep 23, 2009, at 6:09 AM, Kristan Klett <kristan@familie-klett.de> wrote: Terry, thanks for your explanations. Clarifies a lot. So what I have done is to mask out the setgroups() part if restrict_access.c in dovecots code. Hardened the groupID and fixed ACL to Mail-Dirs asf. Just for my curiosity: What changes have been made to dovecot code when it was bundled with SL Server Edition ? There must have been the same issue I encountered Terry Lambert wrote: On Sep 23, 2009, at 2:29 AM, Kristan Klett <kristan@familie- klett.de> wrote: I'm using dovecot as imap mailserver on my Desktop Mac Mini. Since my upgrade to SL I cannot login to imap mailserver because my account is defined to more than 16 groups since having upgraded to SL (not the Server Edition). I can find 19 groups where at least 14 are groups introduced for sharepoint connectivity. dovecot fails with the systemroutine setgroups() Error EINVAL. How can I increase the systemvariable NGROUPS_MAX in order to support 32 groups with the systemcall systemgroups() ? I'd like to increase this without recompiling the Kernel ;-) Directory services supports an arbitrary numbers of group memberships, including groups of groups, and it does so by virtue of the question of enumeration of the groups list for a given user (mostly) never coming up. Instead, all kernel authorization operations around the Tiger timeframe were modified to ask the question "can actor A perform operation B on object C?". At the same time a new field, cr_gmuid was added to the BSD credential, and then the question that gets asked is "is kauth_cred_t a member of group X?" to make group membership based authorization decisions. The first line of inquiry is test_gid vs. cr_groups[0..cr_ngroups], and then if the answer is "no" and cr_gmuid is set, it calls out to user space to ask "is cr_gmuid a member of group X?", which directory services then answers. None of this should keep you out of your IMAP server, since your IMAP server could care less who you really are, so long as your mail client presents a valid account name and SASL password and you get an appropriate euid and egid for file permissions enforcement. However, instead of just being what it's good at and IMAPing away, it looks like your server is calling setgroups() in order to try and be an authentication gatekeeper process and establish real local credentials, instead of the minimum credential that would work. If it's going to do that, it should be a good citizen and use the PAM modules to authenticate against directory services, instead of trying to fake up a credential on its own. If on the other hand it's something like sshd or telnetd, it should be internally running /bin/login to do its session management. For one thing, it will have an incredibly tough time of it unless it calls initgroups instead of setgroups. Even then, it's still going to have a tough time of it because there is a very specific order of operations required to opt a newly created credential into external group membership resolution by directory services, part of which require that both the client and server are bound into the same security association. This is necessary so that the vended group list is identical in both places so directory services gives the same answer to the "is cr_gmuid a member of group X?" question. -- Terry This email sent to site_archiver@lists.apple.com