Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp761415ybb; Thu, 28 Mar 2019 11:38:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqx/x2YMpmUd0TCmJSgVyvwYc8zdyoWgComJr+N2cJBCAcwq3oXrUhJxCjdTkwPgCtDcfS0V X-Received: by 2002:a17:902:d715:: with SMTP id w21mr42337008ply.14.1553798292058; Thu, 28 Mar 2019 11:38:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553798292; cv=none; d=google.com; s=arc-20160816; b=eWFYyfJYT579kwjStpYMSyUcAZRi8XOiZlvkxKqsNp3vz1Oy64RlTHD7V+U0DXz0aQ hRyVan14R/9Ya7oWQWZwXkurM9FEmCG6/FseSKx1hPQOpXorAeEZQ7vUHxueogLYqi+s PyUEtHx2ZZGipQ3JW20TVe452LhwqztvxBJFjZdOG/9ds2F16c1++/1gbv7zy2SRVvG4 ixsVPZNxXeg6D0cAEapksXj9EFLq5uwSgrDyFDGAMaZ+62ERhtSl4nSSoL+5tKinFyLG 1nud5W4DzIJKiapGJcTv8QKGecZHR/H5dqA5mwIdj5C7RRU1Bz68svV3Y04c34hzjoX0 31DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+icrnuII+WR4MaWfSdNX6bx+bEHgcPdBEwfjkhO+ZOc=; b=zvTxo47DV4LQgiQPZ1F8qblcNla2qs39Wq+LOyykwjelelQ+dzcg3tglyMPZxbsgJJ D1p1dk3d8tVO0Jtmt+U5x42ATaxjInfpSHmXyOM9JwcraNPD4QPnfpvzJSmlvKnG37nA jKGSoi8SO73V8N3nmj7mh+mOrsnK/ikztkT4KxSt4pjuN5iAi+RZT/bjTUwZtoN4AnK2 R0qxlwglrr/7Z9OkOWexaqg7Dn3ljneuB98peBATDnnbQYf4I2mwgM66AN8B0EqUFjbj +IWodEg0P9fWxD5SToXkQj5+XirHEQi6GZOWP3dSvgBpnJ+e7XtmW0tE2tKgnYhnCcDx AScw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9si20520124pgp.193.2019.03.28.11.37.55; Thu, 28 Mar 2019 11:38:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726200AbfC1ShJ (ORCPT + 99 others); Thu, 28 Mar 2019 14:37:09 -0400 Received: from mail.hallyn.com ([178.63.66.53]:43614 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725852AbfC1ShJ (ORCPT ); Thu, 28 Mar 2019 14:37:09 -0400 Received: by mail.hallyn.com (Postfix, from userid 1001) id 149A1A74; Thu, 28 Mar 2019 13:37:08 -0500 (CDT) Date: Thu, 28 Mar 2019 13:37:07 -0500 From: "Serge E. Hallyn" To: Dmitry Torokhov Cc: "Serge E. Hallyn" , "Eric W. Biederman" , lkml Subject: Re: Allowing mapping supplemental groups in user namespace? Message-ID: <20190328183707.GA16570@mail.hallyn.com> References: <20190328180503.GA16249@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 28, 2019 at 11:30:52AM -0700, Dmitry Torokhov wrote: > Hi Serge, > > On Thu, Mar 28, 2019 at 11:05 AM Serge E. Hallyn wrote: > > > > On Thu, Feb 28, 2019 at 11:27:38AM -0800, Dmitry Torokhov wrote: > > > Hi Eric, > > > > > > Currently, unless caller has CAP_SETGID in parent namespace, we can > > > only map effective group id in the new user namespace. Would it be > > > possible to relax this rule to also allow mapping of supplemental > > > groups (1:1) of the caller? > > > > > > Thanks. > > > > > > -- > > > Dmitry > > > > Hi, > > > > Is there a use case where adding those to /etc/subgid is onerous? > > (There probably is, just would like to see yours) > > We on Chrome OS limit number of suid binaries installed on the system, > so newgidmap does not have necessary privileges to carry out this good goal in general so long as you don't take a few huge monolithic suid binaries instad of more simpler ones :) > operation. Also we are looking for a solution that we can use with our > minijail package where spawning additional binary is challenging even > if it was suid. Ok. So fwiw I think what you propose should be ok. I think you should post a patch to do it. It's very possible that seeing that patch will remind us of the reason why it *is* a bad idea, but seeing the patch may be a required shock to elicit that memory. -serge