From casper@sac.sfbay.sun.com Thu Oct 8 02:23:36 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n989NaTr004845 for ; Thu, 8 Oct 2009 02:23:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n989NZjX017393; Thu, 8 Oct 2009 02:23:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600H01VFBSZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 02:23:35 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR600G1PVF9W510@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 02:23:33 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n989NWc2016006; Thu, 08 Oct 2009 02:23:32 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n989NBM9004840; Thu, 08 Oct 2009 02:23:11 -0700 (PDT) Received: (from casper@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n989NBkZ004836; Thu, 08 Oct 2009 02:23:11 -0700 (PDT) Date: Thu, 08 Oct 2009 02:23:11 -0700 (PDT) From: Casper Dik Subject: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] To: PSARC-ext@sun.com Message-id: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2502 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Increase the maximum value of NGROUPS_MAX to 1024 1.2. Name of Document Author/Supplier: Author: Casper Dik 1.3 Date of This Document: 08 October, 2009 4. Technical Description I'm sponsoring this fasttrack for myself. Binding: patch/micro This project proposes changing the maximum value for NGROUPS_MAX from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 to 1024. The use for a larger number of groups is described in CR 4088757, particular in the case of Samba servers and ADS clients; the Samba servers map every SID to a Unix group. Users with more than 32 groups SIDs are common. We've seen reports varying from "64 is enough", "128 is absolutely enough" and "we've users with more 190 group SIDS). NGROUPS_MAX as defined by different Unix versions are as follows (http://www.j3e.de/ngroups.html): Linux Kernel >= 2.6.3 65536 Linux Kernel < 2.6.3 32 Tru64 / OSF/1 32 IBM AIX 5.2 64 IBM AIX 5.3 ... 6.1 128 OpenBSD, NetBSD, FreeBSD, Darwin (Mac OS X) 16 Sun Solaris 7,8,9,10 16 (can vary from 0-32) HP-UX 20 IRIX 16 (can vary from 0-32) Plan 9 from Bell Labs 32 Minix 3 0 (Minix-vmd: 16) QNX 6.4 8 The maximum number of groups SIDS in Microsoft appears to be 1024, see http://support.microsoft.com/kb/328889; this is how we arrived at the new maximum limit of 1024. The default value of NGROUPS_MAX will continue to be 16 except for debug builds where NGROUP_MAX will be defined as NGROUPS_UMAX. As part of this case, we're change the "AUTH_SYS" semantics for RPC; rather than failing for users in more than 16 groups, we'd prefer to copy the semantics of others: just drop the additional groups and perform the operation with a reduced set of groups. The loopback RPC is also modified to make sure that loopback RPC will work for processes with more than groups then will fit in the 400 byte allowable in the RPC protocol by dropping additional groups. Ucred routines will shrink the actual size of the ucred exchanges: the ucred structures will "shrink to fit" and only processes which use a lot of groups will pay for this in ucred exchanges. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: on-net 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Nicolas.Williams@sun.com Thu Oct 8 09:20:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98GKuLo012887 for ; Thu, 8 Oct 2009 09:20:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98GKtCI028914 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 09:20:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700J15EQWTV00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 09:20:56 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700AMFEQVYKD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 09:20:55 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n98GH7iT005972; Thu, 08 Oct 2009 11:17:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n98GH7T7005971; Thu, 08 Oct 2009 11:17:07 -0500 (CDT) Date: Thu, 08 Oct 2009 11:17:07 -0500 From: Nicolas Williams Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <20091008161707.GW887@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1118 On Thu, Oct 08, 2009 at 02:23:11AM -0700, Casper Dik wrote: > The use for a larger number of groups is described in CR 4088757, > particular in the case of Samba servers and ADS clients; the > Samba servers map every SID to a Unix group. Users with more > than 32 groups SIDs are common. We've seen reports varying from > "64 is enough", "128 is absolutely enough" and "we've users with > more 190 group SIDS). I've seen claims of nearly 500 groups. > Ucred routines will shrink the actual size of the ucred exchanges: the > ucred structures will "shrink to fit" and only processes which use a lot > of groups will pay for this in ucred exchanges. How does this work? The size of a ucred is not passed around, but required to be ucred_size(3C). I guess receiving code will malloc() ucred_size() bytes, receive the ucred, and realloc() to the correct, smaller size, which would be encoded in a ucred header. Or perhaps you'll be enhancing the ucredsys/doorsys syscalls so that you only alloc as much as needed? Yes, implementation details, I know. But interesting details nonetheless. Also: "yay!" Nico -- From gww@sac.sfbay.sun.com Thu Oct 8 09:59:51 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98GxpRS014293 for ; Thu, 8 Oct 2009 09:59:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98GxliX015889 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 09:59:51 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700E1BGJRWZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 10:59:51 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LOWGJNIRJ5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 10:59:47 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98GxjBZ000585; Thu, 08 Oct 2009 09:59:45 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98GxjGM014291; Thu, 08 Oct 2009 09:59:45 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n98Gxj9h014290; Thu, 08 Oct 2009 09:59:45 -0700 (PDT) Date: Thu, 08 Oct 2009 09:59:45 -0700 (PDT) From: Gary Winiger Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] To: PSARC-ext@sun.com, casper.dik@sun.com Message-id: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 495 > This project proposes changing the maximum value for NGROUPS_MAX > from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 > to 1024. > NGROUPS_MAX as defined by different Unix versions are as follows > (http://www.j3e.de/ngroups.html): > > Linux Kernel >= 2.6.3 65536 Just a note: a (possibly future) change above INT16_MAX will require fixing ON audit code that assumes the maximum number of groups is a "short" -- this would need to be changed to "ushort". +1 Gary.. From bart.smaalders@Sun.COM Thu Oct 8 10:10:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98HALF5014546 for ; Thu, 8 Oct 2009 10:10:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n98HAIkR020693; Fri, 9 Oct 2009 01:10:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700B0PH16TB00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Oct 2009 10:10:18 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR7000HEH15IGC0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Oct 2009 10:10:17 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n98H9Acn017004; Thu, 08 Oct 2009 17:09:10 +0000 (GMT) Date: Thu, 08 Oct 2009 10:08:14 -0700 From: Bart Smaalders Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> To: PSARC-ext@Sun.COM Cc: Gary Winiger , casper.dik@Sun.COM Message-id: <4ACE1C7E.1010202@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 762 Gary Winiger wrote: >> This project proposes changing the maximum value for NGROUPS_MAX >> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 >> to 1024. > >> NGROUPS_MAX as defined by different Unix versions are as follows >> (http://www.j3e.de/ngroups.html): >> >> Linux Kernel >= 2.6.3 65536 > > Just a note: a (possibly future) change above INT16_MAX > will require fixing ON audit code that assumes the > maximum number of groups is a "short" -- this would need > to be changed to "ushort". > > +1 > Gary.. Is there a reason to not go to 32K right away? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From casper@holland.sun.com Thu Oct 8 11:41:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IfY9g016955 for ; Thu, 8 Oct 2009 11:41:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IfVfQ009888 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 8 Oct 2009 19:41:33 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70010HL97N200@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 12:41:31 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LP6L96IXR5@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 12:41:30 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IfRbx064987; Thu, 08 Oct 2009 19:41:27 +0100 (BST) Date: Thu, 08 Oct 2009 20:41:27 +0200 From: Casper.Dik@sun.com Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <20091008161707.GW887@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Casper Dik , PSARC-ext@sun.com Message-id: <200910081841.n98IfRbx064987@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <20091008161707.GW887@Sun.COM> Status: RO Content-Length: 1224 >> Ucred routines will shrink the actual size of the ucred exchanges: the >> ucred structures will "shrink to fit" and only processes which use a lot >> of groups will pay for this in ucred exchanges. > >How does this work? The size of a ucred is not passed around, but >required to be ucred_size(3C). I guess receiving code will malloc() >ucred_size() bytes, receive the ucred, and realloc() to the correct, >smaller size, which would be encoded in a ucred header. Or perhaps >you'll be enhancing the ucredsys/doorsys syscalls so that you only alloc >as much as needed? Yes, implementation details, I know. But >interesting details nonetheless. Ucred is currently formatted like this:
[][] The new generated format is:
cr_ngroups * gid_t>[][] Well, you can't know how big the item you are going to receive and you want to be able to re-use the buffer. (With 1024 groups, you'll need to allocate at least 4K)So in userland you allocate ucred_size(). In the kernel we generate the ucred and we know how big the item is going to be; we allocate as much as we need and we copyout just that data. Casper From casper@holland.sun.com Thu Oct 8 11:44:20 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IiJJX017086 for ; Thu, 8 Oct 2009 11:44:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n98IiEJ1016817 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 9 Oct 2009 02:44:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700001LDT0T00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 11:44:17 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700EGFLDRSR90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 11:44:16 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IiD2L000156; Thu, 08 Oct 2009 19:44:13 +0100 (BST) Date: Thu, 08 Oct 2009 20:44:13 +0200 From: Casper.Dik@sun.com Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> Sender: casper@holland.sun.com To: Gary Winiger Cc: PSARC-ext@sun.com Message-id: <200910081844.n98IiD2L000156@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> Status: RO Content-Length: 626 >> This project proposes changing the maximum value for NGROUPS_MAX >> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 >> to 1024. > >> NGROUPS_MAX as defined by different Unix versions are as follows >> (http://www.j3e.de/ngroups.html): >> >> Linux Kernel >= 2.6.3 65536 > > Just a note: a (possibly future) change above INT16_MAX > will require fixing ON audit code that assumes the > maximum number of groups is a "short" -- this would need > to be changed to "ushort". I found that bit of code; more is needed, specifically adding so much data to a cred without using it. >+1 Thanks, Casper From casper@holland.sun.com Thu Oct 8 11:50:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IoGtD017140 for ; Thu, 8 Oct 2009 11:50:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98IoFFe014517 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 8 Oct 2009 12:50:16 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70020DLNQIO00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 12:50:14 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700L7HLNPILR5@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 12:50:14 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IoAEc001825; Thu, 08 Oct 2009 19:50:10 +0100 (BST) Date: Thu, 08 Oct 2009 20:50:10 +0200 From: Casper.Dik@sun.com Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4ACE1C7E.1010202@Sun.COM> Sender: casper@holland.sun.com To: Bart Smaalders Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <200910081850.n98IoAEc001825@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910081659.n98Gxj9h014290@sac.sfbay.sun.com> <4ACE1C7E.1010202@Sun.COM> Status: RO Content-Length: 913 >Gary Winiger wrote: >>> This project proposes changing the maximum value for NGROUPS_MAX >>> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 >>> to 1024. >> >>> NGROUPS_MAX as defined by different Unix versions are as follows >>> (http://www.j3e.de/ngroups.html): >>> >>> Linux Kernel >= 2.6.3 65536 >> >> Just a note: a (possibly future) change above INT16_MAX >> will require fixing ON audit code that assumes the >> maximum number of groups is a "short" -- this would need >> to be changed to "ushort". >> >> +1 >> Gary.. > >Is there a reason to not go to 32K right away? I think that would require quite different algorithms to scale to that point; as there is a push to do a back-port, I prefer to keep the algorithms the same. I'm removing NGROUPS_UMAX for all the userland code so a later change would be simpler in that no work outside the kernel is needed. Casper From gww@eng.sun.com Thu Oct 8 11:51:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IpYGI017229 for ; Thu, 8 Oct 2009 11:51:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98IpY3H005240 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 11:51:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700501LPXWN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 11:51:33 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700KHYLPW6AD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 11:51:32 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IpVD3020930; Thu, 08 Oct 2009 11:51:31 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n98IoEoj004786; Thu, 08 Oct 2009 11:50:14 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n98IoElQ004785; Thu, 08 Oct 2009 11:50:14 -0700 (PDT) Date: Thu, 08 Oct 2009 11:50:14 -0700 (PDT) From: Gary Winiger Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] To: gww@sac.sfbay.sun.com, Casper.Dik@sun.com Cc: PSARC-ext@sun.com Message-id: <200910081850.n98IoElQ004785@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 803 > >> This project proposes changing the maximum value for NGROUPS_MAX > >> from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 > >> to 1024. > > > >> NGROUPS_MAX as defined by different Unix versions are as follows > >> (http://www.j3e.de/ngroups.html): > >> > >> Linux Kernel >= 2.6.3 65536 > > > > Just a note: a (possibly future) change above INT16_MAX > > will require fixing ON audit code that assumes the > > maximum number of groups is a "short" -- this would need > > to be changed to "ushort". > > I found that bit of code; more is needed, specifically adding so much > data to a cred without using it. Probably off topic, so let's take it off line if there's more to discuss. I was referring to au_to_groups() in the kernel and au_to_newgroups() in userland. Gary.. From Gordon.Ross@sun.com Thu Oct 8 12:59:36 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98Jxasw020180 for ; Thu, 8 Oct 2009 12:59:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98JxVPw003578 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 12:59:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70090HOVBMB00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 13:59:35 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700L0IOVBIPT5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 13:59:35 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n98JxZ0t028948 for ; Thu, 08 Oct 2009 19:59:35 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700100ND16Q00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 13:59:35 -0600 (MDT) Received: from [192.168.1.6] ([unknown] [75.67.12.95]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR70041UOUKNJE0@mail-amer.sun.com>; Thu, 08 Oct 2009 13:59:09 -0600 (MDT) Date: Thu, 08 Oct 2009 15:59:08 -0400 From: Gordon Ross Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> Sender: Gordon.Ross@sun.com To: Casper Dik Cc: PSARC-ext@sun.com Message-id: <1255031948.1079.7.camel@dell6300gwr> MIME-version: 1.0 X-Mailer: Evolution 2.26.3 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> Status: RO Content-Length: 860 I've heard this affects NFS when using AUTH_SYS (still common). What impact will be seen there? Here's a blog with a good description of the NFS problem: http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Increase the maximum value of NGROUPS_MAX to 1024 > 1.2. Name of Document Author/Supplier: > Author: Casper Dik > 1.3 Date of This Document: > 08 October, 2009 > 4. Technical Description > I'm sponsoring this fasttrack for myself. > > Binding: patch/micro > > This project proposes changing the maximum value for NGROUPS_MAX > from 32 to 1024 by changing the definition of NGROUPS_UMAX from 32 > to 1024. [...] From casper@holland.sun.com Mon Oct 12 08:25:38 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9CFPcYv020675 for ; Mon, 12 Oct 2009 08:25:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9CFPXWf002670 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 12 Oct 2009 08:25:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRE0050BQUPJY00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 12 Oct 2009 09:25:37 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRE00JXQQUN22D0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 12 Oct 2009 09:25:35 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9CFPW5A054225; Mon, 12 Oct 2009 16:25:32 +0100 (BST) Date: Mon, 12 Oct 2009 17:25:32 +0200 From: Casper.Dik@sun.com Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <1255031948.1079.7.camel@dell6300gwr> Sender: casper@holland.sun.com To: Gordon Ross Cc: Casper Dik , PSARC-ext@sun.com Message-id: <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> Status: RO Content-Length: 708 >I've heard this affects NFS when using AUTH_SYS (still common). >What impact will be seen there? > >Here's a blog with a good description of the NFS problem: >http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html It is listed in the case materials; the current Solaris kernel will drop any RPC operation where the user is in more than 16 groups. Other implementations will just truncate the number of groups to 16. I'm inclined to follow the market, truncate the group list and then try the RPC operation. It's in the specification. Specifically, I was convinced when I was running with 1000 groups and I was not able to access anything over NFS. Not very practical. Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Mon Oct 12 08:37:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9CFb3ab020980 for ; Mon, 12 Oct 2009 08:37:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9CFavZM019984 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 12 Oct 2009 16:37:02 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRE00409RDQ7V00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Oct 2009 08:37:02 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRE00NQTRDP0O50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 12 Oct 2009 08:37:01 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9CFXdEs014767 for ; Mon, 12 Oct 2009 15:37:00 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-720227 for PSARC-ext@sun.com; Mon, 12 Oct 2009 15:36:51 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-56282114 for PSARC-ext@sun.com; Mon, 12 Oct 2009 15:36:50 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-4222038 for PSARC-ext@sun.com; Mon, 12 Oct 2009 15:36:50 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id DB585194031; Mon, 12 Oct 2009 17:36:49 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 89714194006; Mon, 12 Oct 2009 17:36:48 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n9CFamJQ023383; Mon, 12 Oct 2009 17:36:48 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:36:48 +0200 Date: Mon, 12 Oct 2009 17:35:19 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Gordon.Ross@sun.com, Casper.Dik@sun.com Cc: PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.404sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 12 Oct 2009 15:36:48.0238 (UTC) FILETIME=[CFB0B8E0:01CA4B51] Status: RO Content-Length: 1125 Casper.Dik@sun.com wrote: > It is listed in the case materials; the current Solaris kernel will drop > any RPC operation where the user is in more than 16 groups. > > Other implementations will just truncate the number of groups to 16. > > I'm inclined to follow the market, truncate the group list and then > try the RPC operation. It's in the specification. > > Specifically, I was convinced when I was running with 1000 groups and I > was not able to access anything over NFS. Not very practical. It depends.... If you use the withdrawn POSIX ACL draft, then by truncating the list you will potentially get less permissions. If you use NTFS ACLs that include deny entries this differs. As we are talking about older NFS versions that do not support NTFS ACLs, it seems to be not a security risk to truncate the list. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From casper@holland.sun.com Mon Oct 12 08:47:18 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9CFlI6C021134 for ; Mon, 12 Oct 2009 08:47:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9CFlHOK013244 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Mon, 12 Oct 2009 08:47:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRE0040NRUUVH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 12 Oct 2009 08:47:18 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRE00NDYRUS0D80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 12 Oct 2009 08:47:17 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9CFlC81062215; Mon, 12 Oct 2009 16:47:12 +0100 (BST) Date: Mon, 12 Oct 2009 17:47:12 +0200 From: Casper.Dik@sun.com Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> Sender: casper@holland.sun.com To: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Cc: Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> Status: RO Content-Length: 836 >It depends.... If you use the withdrawn POSIX ACL draft, then by truncating the >list you will potentially get less permissions. > >If you use NTFS ACLs that include deny entries this differs. > >As we are talking about older NFS versions that do not support NTFS ACLs, it seems >to be not a security risk to truncate the list. Well, it could be. You're in groups 0 .. 16 (17 total) There's a file in group 16, mode rw----rw-. However, AUTH_SYS is a security risk in itself and it's easy to fake any group list or uid. Adding a small security issue to a gaping hole isn't worth losing sleep over. The only other issue is that truncating may cause unexplained permission issues. However, not truncating the gid list requires the administrator to give all users at most 16 groups or they won't be able to use NFS. Casper From Nicolas.Williams@sun.com Mon Oct 12 10:25:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9CHPgBJ024095 for ; Mon, 12 Oct 2009 10:25:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9CHPdOC003716; Mon, 12 Oct 2009 18:25:41 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRE00I0FWER7D00@brm-avmta-1.central.sun.com>; Mon, 12 Oct 2009 11:25:39 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRE007U0WEQPB60@brm-avmta-1.central.sun.com>; Mon, 12 Oct 2009 11:25:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9CGaohu007756; Mon, 12 Oct 2009 11:36:50 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9CGanbW007755; Mon, 12 Oct 2009 11:36:49 -0500 (CDT) Date: Mon, 12 Oct 2009 11:36:49 -0500 From: Nicolas Williams Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <20091012163649.GK887@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1068 On Mon, Oct 12, 2009 at 05:47:12PM +0200, Casper.Dik@Sun.COM wrote: > >If you use NTFS ACLs that include deny entries this differs. That's true, but there's just not much we can do about AUTH_SYS, and as Casper says, "AUTH_SYS is a security risk in itself". > >As we are talking about older NFS versions that do not support NTFS ACLs, it seems > >to be not a security risk to truncate the list. NFSv4 ACLs are very much like NTFS ACLs, particularly in that they can have DENY ACEs. > The only other issue is that truncating may cause unexplained permission > issues. However, not truncating the gid list requires the administrator > to give all users at most 16 groups or they won't be able to use NFS. Specifically it may cause non-deterministic behavior. Sorting the group list will cause deterministic behavior, but that is probably worse. Ideally we could just wave our hands and make AUTH_SYS go away. But we can't. What we can do though is this: the NFS server could look up the group memberships of the UID asserted by an AUTH_SYS client. Nico -- From Darren.Moffat@sun.com Tue Oct 13 01:26:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9D8QnaS021304 for ; Tue, 13 Oct 2009 01:26:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9D8QlDg021852 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Oct 2009 09:26:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG0090524NCA00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 01:26:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG003DK24MWH70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 01:26:47 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9D8QjoQ005995 for ; Tue, 13 Oct 2009 08:26:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRF00C00ZS4NJ00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 09:26:30 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRG004E323TRK00@fe-emea-09.sun.com>; Tue, 13 Oct 2009 09:26:17 +0100 (BST) Date: Tue, 13 Oct 2009 09:26:16 +0100 From: Darren J Moffat Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <20091012163649.GK887@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Casper.Dik@sun.com, Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4AD439A8.9070604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 1418 Nicolas Williams wrote: > On Mon, Oct 12, 2009 at 05:47:12PM +0200, Casper.Dik@Sun.COM wrote: >>> If you use NTFS ACLs that include deny entries this differs. > > That's true, but there's just not much we can do about AUTH_SYS, and as > Casper says, "AUTH_SYS is a security risk in itself". > >>> As we are talking about older NFS versions that do not support NTFS ACLs, it seems >>> to be not a security risk to truncate the list. > > NFSv4 ACLs are very much like NTFS ACLs, particularly in that they can > have DENY ACEs. > >> The only other issue is that truncating may cause unexplained permission >> issues. However, not truncating the gid list requires the administrator >> to give all users at most 16 groups or they won't be able to use NFS. > > Specifically it may cause non-deterministic behavior. Sorting the group > list will cause deterministic behavior, but that is probably worse. > Ideally we could just wave our hands and make AUTH_SYS go away. But we > can't. What we can do though is this: the NFS server could look up the > group memberships of the UID asserted by an AUTH_SYS client. That would actually help in a few edge case configs even when the group list is less than 16. Having AUTH_SYS just ignore the supplementary groups all together and collect them itself would be useful - but likely a performance impact since now we need a nameservice lookup. -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Oct 13 03:52:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9DAq5bL024212 for ; Tue, 13 Oct 2009 03:52:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9DAq3nJ029484 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Oct 2009 03:52:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG00J0F8US2G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 03:52:04 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG00EOL8URCVA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 03:52:04 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DAq3Da019049 for ; Tue, 13 Oct 2009 10:52:03 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-3966861 for PSARC-ext@sun.com; Tue, 13 Oct 2009 10:52:03 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-78789859 for PSARC-ext@sun.com; Tue, 13 Oct 2009 10:52:02 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-9010497 for PSARC-ext@sun.com; Tue, 13 Oct 2009 10:52:02 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 931FD6F0523; Tue, 13 Oct 2009 12:51:59 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 127756F0513; Tue, 13 Oct 2009 12:51:58 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n9DApuRf002657; Tue, 13 Oct 2009 12:51:57 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:51:56 +0200 Date: Tue, 13 Oct 2009 12:50:29 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4AD439A8.9070604@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Nicolas.Williams@sun.com, Darren.Moffat@sun.com Cc: PSARC-ext@sun.com, Gordon.Ross@sun.com, casper@sac.sfbay.sun.com, Casper.Dik@sun.com Message-id: <4ad45b75.m2kRU5wEimnvMR1K%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> <4AD439A8.9070604@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 13 Oct 2009 10:51:56.0859 (UTC) FILETIME=[2ED900B0:01CA4BF3] Status: RO Content-Length: 1260 Darren J Moffat wrote: > > Specifically it may cause non-deterministic behavior. Sorting the group > > list will cause deterministic behavior, but that is probably worse. > > Ideally we could just wave our hands and make AUTH_SYS go away. But we > > can't. What we can do though is this: the NFS server could look up the > > group memberships of the UID asserted by an AUTH_SYS client. > > That would actually help in a few edge case configs even when the group > list is less than 16. Having AUTH_SYS just ignore the supplementary > groups all together and collect them itself would be useful - but likely > a performance impact since now we need a nameservice lookup. There may be a problem with not sorting in case that order of the supplemtary groups is a result if hashing or using binry trees in the naming service. Not sorting in such a case could result in non-deterministic behavior after an data base upgrade was done. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Nicolas.Williams@sun.com Tue Oct 13 09:22:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9DGM5cd002063 for ; Tue, 13 Oct 2009 09:22:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9DGM0nM005429; Tue, 13 Oct 2009 09:22:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG00A0JO4OB000@brm-avmta-1.central.sun.com>; Tue, 13 Oct 2009 10:22:00 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG0009OO4N3GC0@brm-avmta-1.central.sun.com>; Tue, 13 Oct 2009 10:21:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DFXBRo008710; Tue, 13 Oct 2009 10:33:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DFXAEx008709; Tue, 13 Oct 2009 10:33:10 -0500 (CDT) Date: Tue, 13 Oct 2009 10:33:10 -0500 From: Nicolas Williams Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4AD439A8.9070604@Sun.COM> To: Darren J Moffat Cc: Casper.Dik@sun.com, Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <20091013153310.GE887@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> <4AD439A8.9070604@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 835 On Tue, Oct 13, 2009 at 09:26:16AM +0100, Darren J Moffat wrote: > >Specifically it may cause non-deterministic behavior. Sorting the group > >list will cause deterministic behavior, but that is probably worse. > >Ideally we could just wave our hands and make AUTH_SYS go away. But we > >can't. What we can do though is this: the NFS server could look up the > >group memberships of the UID asserted by an AUTH_SYS client. > > That would actually help in a few edge case configs even when the group > list is less than 16. Having AUTH_SYS just ignore the supplementary > groups all together and collect them itself would be useful - but likely > a performance impact since now we need a nameservice lookup. There'd be a cache, to avoid having to do these lookups too frequently, and we already do them for secure NFS anyways. From Darren.Moffat@sun.com Tue Oct 13 09:23:39 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9DGNbGg002195 for ; Tue, 13 Oct 2009 09:23:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9DGNbWH043383 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 13 Oct 2009 10:23:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG00G0BO79JE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 09:23:33 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG00A9CO78XS60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 09:23:33 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9DGNW30019341 for ; Tue, 13 Oct 2009 16:23:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRG00200NS9Q400@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 13 Oct 2009 17:23:18 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRG0029AO6TQ200@fe-emea-10.sun.com>; Tue, 13 Oct 2009 17:23:17 +0100 (BST) Date: Tue, 13 Oct 2009 17:23:16 +0100 From: Darren J Moffat Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <20091013153310.GE887@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Casper.Dik@sun.com, Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4AD4A974.8060706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> <4AD439A8.9070604@Sun.COM> <20091013153310.GE887@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 984 Nicolas Williams wrote: > On Tue, Oct 13, 2009 at 09:26:16AM +0100, Darren J Moffat wrote: >>> Specifically it may cause non-deterministic behavior. Sorting the group >>> list will cause deterministic behavior, but that is probably worse. >>> Ideally we could just wave our hands and make AUTH_SYS go away. But we >>> can't. What we can do though is this: the NFS server could look up the >>> group memberships of the UID asserted by an AUTH_SYS client. >> That would actually help in a few edge case configs even when the group >> list is less than 16. Having AUTH_SYS just ignore the supplementary >> groups all together and collect them itself would be useful - but likely >> a performance impact since now we need a nameservice lookup. > > There'd be a cache, to avoid having to do these lookups too frequently, > and we already do them for secure NFS anyways. Of course, but my concern was making AUTH_SYS (the default) slower in the default case. -- Darren J Moffat From Nicolas.Williams@sun.com Tue Oct 13 10:44:51 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9DHioL7004232 for ; Tue, 13 Oct 2009 10:44:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9DHifAq022785; Wed, 14 Oct 2009 01:44:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG00L05RYIJ100@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Oct 2009 10:44:42 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG00KMDRYH4N10@nwk-avmta-2.sfbay.sun.com>; Tue, 13 Oct 2009 10:44:41 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DGtmVT008766; Tue, 13 Oct 2009 11:55:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DGtm9m008765; Tue, 13 Oct 2009 11:55:48 -0500 (CDT) Date: Tue, 13 Oct 2009 11:55:48 -0500 From: Nicolas Williams Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4AD4A974.8060706@Sun.COM> To: Darren J Moffat Cc: Casper.Dik@sun.com, Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <20091013165548.GF887@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> <4AD439A8.9070604@Sun.COM> <20091013153310.GE887@Sun.COM> <4AD4A974.8060706@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1305 On Tue, Oct 13, 2009 at 05:23:16PM +0100, Darren J Moffat wrote: > Nicolas Williams wrote: > >On Tue, Oct 13, 2009 at 09:26:16AM +0100, Darren J Moffat wrote: > >>>Specifically it may cause non-deterministic behavior. Sorting the group > >>>list will cause deterministic behavior, but that is probably worse. > >>>Ideally we could just wave our hands and make AUTH_SYS go away. But we > >>>can't. What we can do though is this: the NFS server could look up the > >>>group memberships of the UID asserted by an AUTH_SYS client. > >>That would actually help in a few edge case configs even when the group > >>list is less than 16. Having AUTH_SYS just ignore the supplementary > >>groups all together and collect them itself would be useful - but likely > >>a performance impact since now we need a nameservice lookup. > > > >There'd be a cache, to avoid having to do these lookups too frequently, > >and we already do them for secure NFS anyways. > > Of course, but my concern was making AUTH_SYS (the default) slower in > the default case. If the client asserts fewer 16 supplementary groups, then the server could skip that lookup. But yes, there'd be cases where the initial AUTH_SYS use would be slower. This feature could be optional, and default to off if that perf issue really matters. From Julian.Pullen@sun.com Wed Oct 14 11:02:02 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9EI21k3015154 for ; Wed, 14 Oct 2009 11:02:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9EI1wbQ012971 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 14 Oct 2009 12:02:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRI0060DNFCW400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 14 Oct 2009 11:02:00 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRI0010LNFBD160@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 14 Oct 2009 11:02:00 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9EI1woT026107 for ; Wed, 14 Oct 2009 18:01:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRI00C00NAX7C00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 14 Oct 2009 19:01:49 +0100 (BST) Received: from [192.168.1.47] ([unknown] [81.168.89.251]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRI00GFKNF0Q480@fe-emea-09.sun.com>; Wed, 14 Oct 2009 19:01:49 +0100 (BST) Date: Wed, 14 Oct 2009 19:03:37 +0100 From: Julian Pullen Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: <4AD439A8.9070604@Sun.COM> Sender: Julian.Pullen@sun.com To: Darren J Moffat Cc: Nicolas Williams , Casper.Dik@sun.com, Joerg Schilling , Gordon.Ross@sun.com, PSARC-ext@sun.com, casper@sac.sfbay.sun.com Message-id: <4AD61279.80509@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080923.n989NBkZ004836@sac.sfbay.sun.com> <1255031948.1079.7.camel@dell6300gwr> <200910121525.n9CFPW5A054225@dm-holland-02.uk.sun.com> <4ad34cb7.UiMhoHzpx3LJOYFZ%Joerg.Schilling@fokus.fraunhofer.de> <200910121547.n9CFlC81062215@dm-holland-02.uk.sun.com> <20091012163649.GK887@Sun.COM> <4AD439A8.9070604@Sun.COM> User-Agent: Thunderbird 2.0.0.22 (X11/20090720) Status: RO Content-Length: 1614 Darren J Moffat wrote: > Nicolas Williams wrote: >> On Mon, Oct 12, 2009 at 05:47:12PM +0200, Casper.Dik@Sun.COM wrote: >>>> If you use NTFS ACLs that include deny entries this differs. >> >> That's true, but there's just not much we can do about AUTH_SYS, and as >> Casper says, "AUTH_SYS is a security risk in itself". >> >>>> As we are talking about older NFS versions that do not support NTFS >>>> ACLs, it seems to be not a security risk to truncate the list. >> >> NFSv4 ACLs are very much like NTFS ACLs, particularly in that they can >> have DENY ACEs. >> >>> The only other issue is that truncating may cause unexplained >>> permission issues. However, not truncating the gid list requires the >>> administrator to give all users at most 16 groups or they won't be >>> able to use NFS. >> >> Specifically it may cause non-deterministic behavior. Sorting the group >> list will cause deterministic behavior, but that is probably worse. >> Ideally we could just wave our hands and make AUTH_SYS go away. But we >> can't. What we can do though is this: the NFS server could look up the >> group memberships of the UID asserted by an AUTH_SYS client. > > That would actually help in a few edge case configs even when the group > list is less than 16. Having AUTH_SYS just ignore the supplementary > groups all together and collect them itself would be useful - but likely > a performance impact since now we need a nameservice lookup. > To avoid a performance hit only only ignore the groups and recompute them from the UID when the number of groups is maxed out. ie 16 groups Regards Julian From casper@holland.sun.com Fri Oct 16 01:58:53 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9G8wrGr027675 for ; Fri, 16 Oct 2009 01:58:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9G8wqeL021328 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Oct 2009 01:58:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRL00405NM47200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Oct 2009 02:58:52 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRL009OPNM2N4C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Oct 2009 02:58:51 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9G8wn00061756; Fri, 16 Oct 2009 09:58:49 +0100 (BST) Date: Fri, 16 Oct 2009 10:58:49 +0200 From: Casper Dik Subject: Re: Increase the maximum value of NGROUPS_MAX to 1024 [PSARC/2009/542 FastTrack timeout 10/14/2009] In-reply-to: To: pluknet Cc: opensolaris-arc@opensolaris.org, PSARC-ext@sun.com Message-id: <200910160858.n9G8wn00061756@dm-holland-02.uk.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: Status: RO Content-Length: 1050 [ Resend as it didn't make the PSARC case log ] >On Thu, Oct 08, 2009 at 02:23:11AM -0700, Casper Dik wrote: >> NGROUPS_MAX as defined by different Unix versions are as follows >> (http://www.j3e.de/ngroups.html): >> >> Linux Kernel >= 2.6.3 65536 >> Linux Kernel < 2.6.3 32 >> Tru64 / OSF/1 32 >> IBM AIX 5.2 64 >> IBM AIX 5.3 ... 6.1 128 >> OpenBSD, NetBSD, FreeBSD, Darwin (Mac OS X) 16 > >This article is a bit outdated (and apache claims the document date is >13/Jul/09). >This is no longer true for FreeBSD 8+, as it was bumped there to 1023. Thanks for that correction. >See early discussion and proposed change. >http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-05/1086.html >http://lists.freebsd.org/pipermail/freebsd-hackers/2009-June/028939.html Thanks; I'm not expecting everyone change the default configuration so we're not, for now, changing how credentials are handled in the kernel. Since I've seen two +1 and no -1 and the timer has run out, I'm marking this fasttrack as approved. Casper