Re: Increasing NGROUPS_MAX
Re: Increasing NGROUPS_MAX
- Subject: Re: Increasing NGROUPS_MAX
- From: Terry Lambert <email@hidden>
- Date: Wed, 23 Sep 2009 11:03:05 -0700
Honestly, I don't know.
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.
Have you tried asking the mail server team?
-- Terry
On Sep 23, 2009, at 6:09 AM, Kristan Klett <email@hidden>
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
Kristan
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 ;-)
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
_______________________________________________
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