From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 0A1FF20922 for ; Thu, 11 Apr 2024 04:59:03 +0200 (CEST) Received: (qmail 23685 invoked by uid 550); 11 Apr 2024 02:58:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23647 invoked from network); 11 Apr 2024 02:58:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1712804329; x=1713409129; i=nullplan@gmx.net; bh=k35fccwDx+T+z/87Qk8VKArGUnGYeDOTf4q0GvquBRI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=jC0AfWsoVgPEYGKWC2XAUoKy+GGvdlJYLyl0XVBMPY7Sobyr4AHPHjPKKy4kFtXP f5CGmmzc4dEIcJ5JpclR3Wznir5Ae54ROdQtlaZqFpyj7vCQL9Vn0XbnbDh5vkf5/ cY3HdvD+/tbzfY4adXjCqVnCVtbO0grSHSOtnX1Y2WGaDfVa0zvsWe5jtoH+8gW9X mNOFBIwR1yKs5z222uiuJQhKPo6D81432PgT4lxQB2NXtCG1r/8WqSRKwy9H11bGW JN6vy7xEvCAnDn6I32e/MND0twTVFtCSQ8Ez54fW61cJWPVe8afiTS64ezNOVp4yr m0fKX5Tp6bPM1WqfQQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 11 Apr 2024 04:58:48 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Kate Deplaix Message-ID: References: <20240411010738.GY4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240411010738.GY4163@brightrain.aerifal.cx> X-Provags-ID: V03:K1:Tu+hkJCCob5K6VRnwtiirBYGhiZB2T2ikLkh0L4Bpk5sr0z1ony skNPenumwiRZ0WzVrwIU9Seam05WNRgVnOwGzrDwxXmSpHf9l0EYH4VEMJo6q5ku7h2ueuV xuxoTP1nFN7LHK8eYTRxQbtJsJaa9pBL7VrgjJXgUUb+X4luGEyyghc9MheSlgL3GiYhrXi A42OtHhi6+eogwRw5oIhw== UI-OutboundReport: notjunk:1;M01:P0:QjoGFb39nrk=;u4GjqLVdmoaavysju2HhX83hTVq vjJoQPdwbUT3KF1AhlJApfZ1ADshC7TRyb5DCrY3HHaaMb913D/XQIF/B37jQP0b/lKaaPItz 5PwFDFsaZfpu2F6ana3nXqylIuTrqPn6KnDPfqjXMyEtHJHPC6UcivDRjhQFJX7+r/kMvxMws Mc+Jdjup7nXZWKa0u4F7mP9I3AysIDywgClQWm5+fvTl2Vhb7/xR9N3ha04fM3AinWQYFfg8j PipkVEHP96PZVHbkm/RMOuTiz/jiyCtWQ1Y//2XiZo4bTEuJKVNIqILlTRsW7l0UeQfff/wVw mjU6ji5fu6n4Q3ffUuenE+OUUyk3dJRd0iIFme29K0PH1i88CuKZ+1dbr5cqNbaOCKNKJxe1V kuSu2gZRb2w54/9cDSHaDrqOMAZADCGvwmevfWxqYqSwkKmfFl0RhNQXo6E6dApI9fbq3ky/T NNP/yEuoSlz/WxNslGzHF8dC3YdXdNnHB+uipKw7VnDchENTBvlzGwuoseGzNrFWm/KjaLKGG L+K9hATL2jDbdUvivA7BNu0P+SlqlSmpZ3aCuP+Rv8ptMT9kO8oqIot6KhoWeO4UHe/SAUlWA X3QQEX7h6kKMckGZk/qtvipLMdns2fzoFpAKp8cxZJK8Hb8ra+KNcxi2W+JJ1z7iaCawSY/AS jORlUrAFkOPOsjDCqgMb/s9cX8MjMSGBHUBMgf+d1g1DQvuryOGm/qWbJljYovokPOPo5sCge tqXjAPbyc/bprEWT4/PDrgdR2AsB77xbtQ96w0EH6w2qpOuOkGIuCJvVcwiS+kIuL382h/eV1 8AKj/MuYO3xkolZKgDMGljZdPpyTda45lHIJBEmSY1nZs= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] Increase NGROUPS_MAX from 32 to 1024 Am Wed, Apr 10, 2024 at 09:07:38PM -0400 schrieb Rich Felker: > As for the macro, I think it's actually valid to define it as 65536, > since even if we're running on an old kernel, there is no conformance > distinction. I'm not sure if this is the nicest thing to do though. > Apps may want to start with a buffer of size NGROUPS_MAX and increase > it up to the sysconf value rather than allocating a giant amount of > memory that will never in practice be used. This should be further > discussed, particularly what impact it might have on application > behavior and memory usage. > I had a look at Debian Codesearch for NGROUPS_MAX, to see what applications are actually doing with the macro. And I found no instance of anyone using it as an array size. That's what had me most worried, because obviously increasing an array size by a few orders of magnitude can cause a stack overrun. A lot of applications use it or the sysconf() equivalent as upper bounds for allocations, or even for setgroups(). So they should be fine with an increase. > It does have a TOCTOU race if the groups db changes > between the first call and the retry. Well, a lot of the login process has races if the user db changes during the process. I think that is reasonable. As long as the race is resolved in a safe way (as in, setting either the complete old list or the complete new list), I think this is sensible. Although, now that I think about it, the worst that could happen is someone being added to a group and getting a truncated group list. And then they just have to re-login. Which they already have to do anyway after being added to a group; they were just too fast. Ciao, Markus