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

Jordan Brown <Jordan.Brown@oracle.com> Wed, 02 December 2015 02:22 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 478DC1B3133 for <ldapext@ietfa.amsl.com>; Tue, 1 Dec 2015 18:22:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_34=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sJvzxF6fKFvI for <ldapext@ietfa.amsl.com>; Tue, 1 Dec 2015 18:22:04 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com []) (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 4DCE21B3132 for <ldapext@ietf.org>; Tue, 1 Dec 2015 18:22:04 -0800 (PST)
Received: from userv0021.oracle.com (userv0021.oracle.com []) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB22M2VF003891 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2015 02:22:03 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com []) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB22M26r024703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 02:22:02 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com []) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB22M197009729; Wed, 2 Dec 2015 02:22:02 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Dec 2015 18:22:01 -0800
To: Simo Sorce <simo@redhat.com>
References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <1449019308.9040.38.camel@redhat.com>
From: Jordan Brown <Jordan.Brown@oracle.com>
Message-ID: <565E55C3.9080404@oracle.com>
Date: Tue, 01 Dec 2015 18:21:55 -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: <1449019308.9040.38.camel@redhat.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: userv0021.oracle.com []
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/xWjpKaMMkg_zJKlOy-nbm_08GoM>
Cc: "'ldapext@ietf.org'" <ldapext@ietf.org>
Subject: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary)
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: Wed, 02 Dec 2015 02:22:06 -0000

[ Splitting off a subtopic as Michael requested. ]

On 12/1/2015 5:21 PM, Simo Sorce wrote:
> On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote:
>> There are two problems there:
>> 1)  A group could contain anything, even when you want it to only
>> contain one type. [...]
> This is very true and there are products that can cope, there are also
> mechanism to more efficiently (at least latency wise) if you use
> controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00
> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use
> it in various clients.

That control is indeed very interesting.  I don't immediately see how it helps 
with the type-safety problem, though.  Am I missing something?

>>   I think the truly right answer there is to add new APIs that don't
>> retrieve the members, and even to redefine the existing APIs to not
>> retrieve the members, because there are almost no cases where it
>> actually makes sense to retrieve the list of members of a UNIX group.
> It would be nice to have a new API, although Posix has some wiggle room
> which we fully exploit in clients like Windbind and SSSD.
> Both clients simply do not return all members in the enumeration cases
> (getgrent) but only in the explicit group retrieve case (getgrnam).
> This is because Posix allows to omit results in the enumeration case
> according to some interpretations.

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.

> Indeed, some admins complain about this so switches are provided in the above 
> mentioned clients to behave "the classic way". And surprisingly very few systems 
> really have a big issue with this. Given that any application that depends on 
> full group enumeration is already fully broken and a performance liability on 
> any enterprise system that has accounts in the thousands. 

Right.  The old "walk through all of the groups and then through all of their 
members" strategy is doubly wrong:  the number of groups can be very large, and 
the number of members of each group can be very large.

Heck, even with RFC2307 memberUid groups, simply retrieving the group list can 
easily involve moving half a megabyte of data. That's a lot of wasted processing 
when all you really wanted was a gid<->name lookup.

>> As long as we're talking about flaws in groupOfNames:  there's also
>> the problem that "member" is a MUST attribute, and that makes empty
>> groups problematic.
> This was, in fact, such a big problem that in the FreeIPA product we
> decided to break with the standard and changed member to be MAY, never
> looked back on this choice.

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.