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

Andrew Findlay <> Fri, 04 December 2015 18:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 944921B2BCB for <>; Fri, 4 Dec 2015 10:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r7dSjdi0n8SI for <>; Fri, 4 Dec 2015 10:39:58 -0800 (PST)
Received: from ( [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D7AF1ACD48 for <>; Fri, 4 Dec 2015 10:39:58 -0800 (PST)
Received: from ([2001:8b0:8d0:f7e1::94] by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1a4vGr-0007zj-Dj; Fri, 04 Dec 2015 18:39:53 +0000
Received: from andrew by with local (Exim 4.85) (envelope-from <>) id 1a4vGq-0002jB-UV; Fri, 04 Dec 2015 18:39:52 +0000
Date: Fri, 04 Dec 2015 18:39:52 +0000
From: Andrew Findlay <>
To: Simo Sorce <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <>
Archived-At: <>
Cc: "''" <>
Subject: Re: [ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

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.

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|                +44 1628 782565     |