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, 04 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 | -----------------------------------------------------------------------
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Steven Legg
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Ludovic Poitou
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- [ldapext] Case sensitivity of user/group names (w… Jordan Brown
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Simo Sorce
- [ldapext] Using groupOfNames (or similar) for UNI… Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Bannister, Mark
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] Using groupOfNames (or similar) for… Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Oza, Dhairesh
- [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- [ldapext] draft-masarati-ldap-deref as ldapext wo… Michael Ströder
- Re: [ldapext] Case sensitivity summary Simo Sorce
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Howard Chu
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Simo Sorce
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- Re: [ldapext] Using groupOfNames (or similar) for… Andrew Findlay
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity summary Bannister, Mark
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Bannister, Mark