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

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