Re: Increasing NGROUPS_MAX
Re: Increasing NGROUPS_MAX
- Subject: Re: Increasing NGROUPS_MAX
- From: Kristan Klett <email@hidden>
- Date: Wed, 23 Sep 2009 15:09:00 +0200
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
Kristan
Terry Lambert wrote:
On Sep 23, 2009, at 2:29 AM, Kristan Klett <email@hidden>
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 ;-)
You can't do that, and you should not be trying.
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
--
****************************************************************
Kristan Klett mobile: +49-172/8326305
Hedwig-Kettler Strasse 18A Tel : +49-40/251523-141
23843 Bad Oldesloe mailto:email@hidden
Germany http://www.sundragons.de
****************************************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden