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

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 04 December 2015 18:40 UTC

Return-Path: <andrew.findlay@skills-1st.co.uk>
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 944921B2BCB for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 10:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 r7dSjdi0n8SI for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 10:39:58 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7AF1ACD48 for <ldapext@ietf.org>; Fri, 4 Dec 2015 10:39:58 -0800 (PST)
Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4vGr-0007zj-Dj; Fri, 04 Dec 2015 18:39:53 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4vGq-0002jB-UV; Fri, 04 Dec 2015 18:39:52 +0000
Date: Fri, 4 Dec 2015 18:39:52 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Simo Sorce <simo@redhat.com>
Message-ID: <20151204183952.GB8983@slab.skills-1st.co.uk>
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> <565E55C3.9080404@oracle.com> <1449076861.9040.56.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1449076861.9040.56.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/gQK4W7m5Qw7ABN2nBAbHE7bZKao>
Cc: "'ldapext@ietf.org'" <ldapext@ietf.org>
Subject: Re: [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: Fri, 04 Dec 2015 18:40:00 -0000

On Wed, Dec 02, 2015 at 12:21:01PM -0500, Simo Sorce wrote:

> > >>   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.

+1 (at least!)

> > > 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.
> 
> 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.
> 
> After all the texts are vague and you could think that the security
> measure expressed here is about not revealing group names.

I think this is a very valuable insight. Any program that expects to
enumerate the whole password or group database is a liability and this
has been the case since Unix escaped from Bell Labs.

In the 1980s there was a machine called Pyramid: it had a hashed database
for /etc/hosts but it searched /etc/group and /etc/passwd linearly. We
had one at the university for undergrad use so both files were quite
large by the standards of the day (5000 entries - seems trivial now!)
The result was very slow logins for people near the end of the file.
This took a while to notice as all the computing staff were at the front...

Following the POSIX stuff a bit further, getgrnam() refers to grp.h:

	http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/grp.h.html

Donning a definition-lawyer's pedantic wig I find this:

------------------------------------------------------------------------
The <grp.h> header shall declare the group structure, which shall include the following members:

char   *gr_name The name of the group. 
gid_t   gr_gid  Numerical group ID. 
char  **gr_mem  Pointer to a null-terminated array of character 
                pointers to member names. 
------------------------------------------------------------------------

That last field is interesting. There are pointers to member names, but
it does *not* say that *all* members will be listed. Taken with the 'extended
security controls' applicable to getgrent() I take this as approval to
return only the data that an application would reasonably need.

Certainly a new API would be better, but I think a config option to
'do the efficient thing' would be very reasonable.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------