Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary)

[Jordan Brown <[e-mail]>]

On 12/2/2015 9:21 AM, Simo Sorce wrote:
> On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote:
>> [draft-masarati-ldap-deref-00] is indeed very interesting. I don't
>> immediately see how it helps with the type-safety problem, though.
>> Am I missing something?
> The idea is that you can get all data up at once including objectclass
> and then you can simply drop results that do not have the right
> objectclass value.
> It is a little more wasteful than being able to specify a secondary
> filter (that would probably be a great addition to the draft), for the
> search done on the attribute of the group entry, but it is still good
> enough to efficiently get results as well as easily weed off unwanted
> ones.

OK, sure.  (Better still would be to have some way to tell the directory to limit 
the types allowed.)
>> Yes, and I infer that there's corresponding omissions in other parts of the 
>> standard. In the getgrent description, the standard describes omitting this 
>> information on the basis of security restrictions. Omitting the data there 
>> would not help security at all if you could immediately turn around and request 
>> it through getgrname and getgrgid. Meeting the security need would require 
>> having the restrictions in both places. 
> True, but are not doing this for security reasons, we are just taking
> the fact that omissions are permissible as a blanket permission to omit
> results, and clients should be prepared to deal with that.

Right, but the standard describes it in terms of security.

> After all the texts are vague and you could think that the security
> measure expressed here is about not revealing group names.

It explicitly mentions editing the list of members (emphasis added):

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrent.html

    An implementation that provides extended security controls may impose further
    implementation-defined restrictions on accessing the group database. In
    particular, the system may deny the existence of some or all of the group
    database entries associated with groups other than those groups associated
    with the caller *and may omit users other than the caller from the list of
    members of groups in database entries that are returned*.


> The fact you can easily scan the whole group ID space is just the
> annoying consequence of the fact most systems do not have a randomized
> ID assignment policy and have a pretty limited ID space at just 32bit of
> size or less. But hey, that's not my fault! :-)

That too, but I was thinking about the list-of-members part... if you have a 
security reason for keeping the list of members hidden, it wouldn't do you any 
good to hide it from getgrent when the caller could then immediately retrieve it 
using getgrgid.

>> We could address it through introducing a new object class (and here I include
>> just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just
>> creating a wholly new one), or by changing the definition.  This is one of those
>> cases where I'd say that breaking formal compatibility might well be appropriate.
> Yes, it would be nice to change the class, because it is forward safe to
> do so, if you created objects when the MUST was in place, nothing breaks
> if you relax the constraint to MAY, at least from the POV of data
> consistency in the directory.
>
> And I never found any software the specifically rely on the fact you
> can't delete the last member attribute from a group for something.
> Actually usually I saw software that had to use workarounds like adding
> the group dn to itself (and concealing the self-reference in the UI)
> when an admin wants to remove the last member but not remove the whole
> group.

The potential problem is a consumer that knows that the "member" attribute MUST be 
present, and freaks out if it isn't.