Re: LDAP Groups topic split-out

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.