Re: [ldapext] DBIS - new IETF drafts

Charlie <> Mon, 13 January 2014 17:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B62DC1AE19C for <>; Mon, 13 Jan 2014 09:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WW0KVMNQw06C for <>; Mon, 13 Jan 2014 09:21:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22e]) by (Postfix) with ESMTP id CC7BB1ADFD4 for <>; Mon, 13 Jan 2014 09:21:20 -0800 (PST)
Received: by with SMTP id p9so3647624lbv.5 for <>; Mon, 13 Jan 2014 09:21:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=BDmhmgeynVvu1NN6HFbcTKQUEWDE8cSD3fxY8i4qOho=; b=OULhnjaLw2kQby4HdbWn44XQZ4lRqQ4Oma9C6VudPJoBMrwKkU1WnGVzOBDCNKn0d9 drDPOhmRQU+o3PTvg1uCYq4AVoJoUWJp65bGHBiVIuzwpCAeWjPIn+duixo1A4ey0ZHl tJD4NYUMn0oK28utiMcu+I7a1Xms0fyLel9cpmWXwqIKR1BWtMqttaMzzTFLRbvWm4bc Mj8haWGW0sFsaylZcNNd9gq4LDT3/r3981Wt4S01it1EFQkrt8edh0f6bdzN6lB2Ka/d cNAxBbu5UZmcA/mAyIyK0YlH0KCySvLIBPGhykyrq9ZWdduF9vt1sQlL/DWDzKDtgl/3 IOZg==
MIME-Version: 1.0
X-Received: by with SMTP id an8mr4775890lac.39.1389633666619; Mon, 13 Jan 2014 09:21:06 -0800 (PST)
Received: by with HTTP; Mon, 13 Jan 2014 09:21:06 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 13 Jan 2014 12:21:06 -0500
Message-ID: <>
From: Charlie <>
Cc: ldapext <>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [ldapext] DBIS - new IETF drafts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jan 2014 17:21:23 -0000

I (Charlie) said:
> 2) POSIX group semantics are the bane of open-source LDAP.  The
> functional paradigm that a member is an attribute of a group is
> fundamentally broken; group membership is an attribute of the member.
> The security concerns frequently raised concerning this are all either
> trivially solvable or pragmatically completely bogus.

Howard replied:
>Sorry but that makes no sense. It's the same as saying 'element e is a member of set S' >is true but 'set S contains element e' is false. If one is true then both must be true.

Perhaps I'm not conveying the concept well.  I'm talking about how
something is expressed and the results certain semantics actually have
on real life, on real human endeavors.  I'm not talking about the
academic equivalency of two forms of symbolic expression.

But it's true that it's no more difficult to add a "memberOf"
attribute to an object than it is to add a "Member" attribute to
another object.  The spurious efficiency of querying LDAP for a member
list (at least one member of which will be queried *again* nearly one
hundred percent of the time) instead of querying against a membership
filter is a mental bugaboo that has retarded progress in LDAP-capable
directory software.

POSIX group lists are an ill-considered hack that somebody (I think
Ritchie) haphazardly pasted onto Unix when they were still trying to
interact with GECOS systems.  They infect the filesystem paradigm and
the user management paradigm and make *nix lamer than it needs to be.
They discourage group nesting and just-in-time resolution and other
desirable practices that exist in the real world that directories are
trying to usefully represent.  Their flat list design ignores human
psychological and empirical organizational realities.

Dynamic groups and/or stored group queries are better, although I've
never seen an optimal implementation of either.  The groups that
people REALLY need to represent in their directories are things like
"the set of people on site competent to reconstitute the threadline"
and "the set of employees accessing the reactor robotics right now"
and "the set of objects in route to Dusseldorf".  Enterprise
directories that try to accurately model reality as it exists will be
far more pragmatically useful than those that simply regurgitate
inherently error-prone and outdated static lists.

POSIX groups suck.  They are the second worst thing in *nix.  OK,
maybe the 3rd.  A directory should never model /etc/groups... yes, it
should be able to generate group lists for POSIX compatibility, but
internally a directory should attempt a more powerful cognitive model
than a grocery list.

If people want to discuss this more, please split the topic off from
Mr. Bannister's thread or contact me privately, since he's already
replied to my post.