Re: [ldapext] LDAP Groups topic split-out

Jordan Brown <Jordan.Brown@oracle.com> Fri, 04 December 2015 00:33 UTC

Return-Path: <Jordan.Brown@oracle.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34F1B2B59 for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 16:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrSfLjbMBMId for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 16:33:50 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5251B2B54 for <ldapext@ietf.org>; Thu, 3 Dec 2015 16:33:49 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB40XiaH026140 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 00:33:45 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB40XiFh001426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 00:33:44 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB40Xits003664; Fri, 4 Dec 2015 00:33:44 GMT
Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 16:33:44 -0800
To: Charlie <medievalist@gmail.com>, ldapext <ldapext@ietf.org>
References: <CAJb3uA57jHCfhN6tQB6Kc7uOGF3g4w6GVmr6+OnhD4=k5zqEzw@mail.gmail.com>
From: Jordan Brown <Jordan.Brown@oracle.com>
Message-ID: <5660DF62.5000800@oracle.com>
Date: Thu, 3 Dec 2015 16:33:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <CAJb3uA57jHCfhN6tQB6Kc7uOGF3g4w6GVmr6+OnhD4=k5zqEzw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/vLaXRf-JUFuqKLxEP7CYAX5q9bE>
Subject: Re: [ldapext] LDAP Groups topic split-out
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 00:33:52 -0000

On 12/3/2015 3:12 PM, Charlie wrote:
> After reading David Foster Wallace on set theory, I wrote an RFC a
> couple years back to address the lack of a generic or globally useful
> grouping mechanism in LDAP-accessible directories.  Comments are
> welcomed.
>
> http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt

3.1.

Properly, Boy Scout and Scout are capitalized.

In the general case, I'd say that it's equally correct to say that the list of 
Scouts is an attribute of the troop and to say that membership in the troop is an 
attribute of the particular Scout. It's an N:M relationship; it can be approached 
from either direction.

(I had not realized until I got to the discussion in D.2 that a mailing list was 
best served by member-of attributes.  One would think that it would be best served 
by a member-list attribute, but you're absolutely correct that using a member-of 
attribute reduces the number of queries in the common case.)

For an indexed database, it's probably OK to represent the relationship in either 
direction.  For a database that understands the relationship, the relationship 
might be visible on both sides and the connection automatically maintained.

For simpler databases, indeed maintaining "member-of" is probably better, both 
because it's convenient for the common queries and because it's probably a smaller 
list than the "members" list.

(But note:  it's not at all obvious which variation is better from an access 
control standpoint.  Is it more likely that you will want to hide the membership 
of group X, or the list of groups that user Y is a member of?  Presumably if you 
want to do either, then you need to ensure that that membership linkage, however 
it is presented in the directory, is subject to access control restrictions.)

3.4.

Empty sets are also useful in trivial cases, e.g. when creating a set and before 
populating, and as a possible intermediate state while adding and removing members.

3.5

I'm not convinced that "proxy" objects (which you call "dummy" objects) aren't the 
right answer.  Directly referring to external objects assumes that there's no need 
for auxiliary data about those objects.

(Hmm.  Is there a need to describe auxiliary information about a particular 
membership relationship?  For instance, for a mailing list, might one want to 
maintain a count of messages from a particular list to a particular user that have 
bounced?)

4.4

I'm not convinced that an undefined "scope" attribute is helpful.

4.5

psetMembership seems like overkill, though its ability to represent dynamic sets 
is interesting.

5.3

If recursion is always expanded by the client, there's no need for timeouts on 
queries to prevent DoS.  The clients can decide on their own when to stop recursing.

C.1, C.2

I thought that memberOfPset contained DNs.

D.5

posixGroup has memberUid as a MAY attribute and so *can* represent empty sets.


> If you're not up for a long-read, I would recommend just reading
> "Appendix D:  Other Efforts and their Shortcomings" which explains all
> the attempts to date and how they've failed to gain traction.
>
> Projects continue to try to solve their individual problems instead of
> working towards a truly generic grouping mechanism that will suit all
> needs, so nothing's progressing.  Simo mentioned this in the context
> of FreeIPA, for example - they broke their implementation of RFC2307
> and moved on, rather than helping Andrew Findlay create a standard
> that supported empty groups.  It seems like each of us is focused on
> our own potato patch.
>

Actually, here in the Solaris Naming organization, mostly our assumption is that 
we have to live with whatever the directory gives us, that the directory was 
established by the enterprise before we arrived on the scene and so our ability to 
influence it is minimal. We might participate in an effort such as this one to try 
to nudge the future in a desirable direction, but the assumption is that no one 
scheme will ever achieve such dominance that we can ignore the others.  Of course 
I would be happy to be proven wrong so that we could remove a bunch of flexibility 
that's associated with the need to interoperate with such a variety of schemata.