From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 252EE1F463 for ; Mon, 30 Sep 2019 12:06:22 +0000 (UTC) Received: from localhost ([::1]:51136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEuRY-0000ht-H7 for normalperson@yhbt.net; Mon, 30 Sep 2019 08:06:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58953) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEuRU-0000hg-73 for bug-gnulib@gnu.org; Mon, 30 Sep 2019 08:06:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iEuRT-0001Qr-4K for bug-gnulib@gnu.org; Mon, 30 Sep 2019 08:06:16 -0400 Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::11]:19593) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iEuRS-0001Mv-E4 for bug-gnulib@gnu.org; Mon, 30 Sep 2019 08:06:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1569845169; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=zDcVNcxDlypziBDPxn7VcxgF4XpHfUE6mLwlp1mc+v4=; b=rrRTuAJG2relFZjvwdu2CgZMqY/SOzwV7n4qjNvOR8mh1jogwimATuqvMDmtOYAZzQ ZLJQdj87JMYNp+ENzXvCBVbAffdlYna0aqqLkE9VKmhssVYMdTP6JSQJjNLI/jlTG5Jk KlaOmTK8o9378BFvlPTf8UPluCvbVoLkM0EkumvzW3bofzVlklRD4gL9oUkochjnd8/m 1aLjddJLc4YznJYQ63fZiHN2nAmf59OY3wTOL7Sj2gnVR8QjYBVKUkanjrrTf057TbK/ dcAmbj0m94cawETxC6lpbKxVkbYGdLqtzUp44XMk134O9m1MQUldfiulM6zUDk3bSzza VBVA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGaf0zJZW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 44.28.0 DYNA|AUTH) with ESMTPSA id N06099v8UC67fek (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 30 Sep 2019 14:06:07 +0200 (CEST) From: Bruno Haible To: Daniel =?ISO-8859-1?Q?P=2E_Berrang=E9?= Subject: Re: [libvirt] Fwd: libvirtd failing on MacOS in setgroups Date: Mon, 30 Sep 2019 14:06:07 +0200 Message-ID: <1703015.ZU562xqnTS@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-159-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20190930090211.GA11996@redhat.com> References: <2228634.vrrhnCLpfL@omega> <20190930090211.GA11996@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::11 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, Eric Blake , Roman Bolshakov , bug-gnulib@gnu.org, Marcus Furlong Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Daniel P. Berrang=E9 wrote: > > > FWIW I compiled libvirt without the setgroups code on Mac and it > > > worked as expected. Not sure what the implications of that are though? > >=20 > > OK, then the fix would be to not use setgroups on Mac, and nothing to do > > in gnulib. Right? >=20 > Not calling setgroups means the QEMU process doesn't run with any of > the supplementary groups associated with its user account, so this is > not really a working solution. It re-introduces the bug that the > setgroups call was added to fix. =46or what purpose is libvirt or QEMU using setgroups()? What goes wrong if setgroups() fails? The problem is that the Darwin kernel does not support setting more than NGROUPS_MAX (=3D 16) groups. So - What happens when you have a user account which is in more than 16 groups? What do other processes do in this sitation? - Is using the first 16 groups and ignoring the extra ones an acceptable solution? Bruno