From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759567AbbIVVwT (ORCPT ); Tue, 22 Sep 2015 17:52:19 -0400 Received: from smtp.gentoo.org ([140.211.166.183]:38219 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbbIVVwR (ORCPT ); Tue, 22 Sep 2015 17:52:17 -0400 Date: Tue, 22 Sep 2015 17:52:15 -0400 From: Mike Frysinger To: "Eric W. Biederman" Cc: linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org Subject: Re: handling of supplemental groups with userns Message-ID: <20150922215215.GE27286@vapier.lan> Mail-Followup-To: "Eric W. Biederman" , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org References: <20150922162157.GB27286@vapier.lan> <87d1xafdk8.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wtjvnLv0o8UUzur2" Content-Disposition: inline In-Reply-To: <87d1xafdk8.fsf@x220.int.ebiederm.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --wtjvnLv0o8UUzur2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 22 Sep 2015 14:40, Eric W. Biederman wrote: > Mike Frysinger writes: > > is it possible to map in supplemental groups in a userns when the user > > lacks setgid/etc... capabilities in the parent ns ? it doesn't seem > > like it's currently possible, but is there a reason to not enable it ? >=20 > In your unprivileged use scenario, you won't be able to drop > your supplementary groups so why do you need them mapped? >=20 > > basically i have a build tool that i want to isolate a bit, but it > > requires access to some of my supplemental groups. if i map just > > my effective uid/gid, the build will fail when it tries to use the > > chown/chgrp commands (gets back EINVAL). >=20 > Yes. That really isn't valid as you are dropping groups. Peculiarly > enough dropping groups can be a security issue as in some permission > checks not being a member of a group can give you enhanced access to > files and directories. i don't want to drop groups ... i want the exact opposite actually :). ideally, `id` would have the same output before/after. instead, i get 65534 for all the supplemental groups. these commands work before i create a new userns and i want them to keep working afterwards: chgrp 100 foo chgrp 250 foo instead, only the first works (since that's my effective gid) and the second fails (since i'm in that via a supplemental group). > So to do something like what you want, you need a setuid helper (something > like newuidmap or newgidmap) to verify that what you are doing is ok > by local policy. i know i can get it ahead of time if i have the caps apriori, but that's not what i want to require. if i had those, then i would generally be able to simply create the namespaces directly and not bother with userns in the first place :). > > my scenario boils down to: > > - normal unprivileged user (uid=3D8282) > > - member of multiple groups (gid=3D100, getgroups=3D{100,16,250,...}) > > - create a new userns (to get access to other ns like mount/pid) > > but still have access to existing groups where i'm root > > - use various features that require caps (new pidns/mntns/etc...) > > - create another userns and map back non-root users/groups > > i.e. i switch from 8282 to 0, do what i need, then switch back to 8282. >=20 > [snip] >=20 > > in the mean time, a "quick" fix might be to change new_idmap_permitted > > to walk all the extents, and if all the ranges are set to 1, check the > > supplemental groups in addition to the current egid ? >=20 > That allows dropping groups that you could not drop normally and so we > can't allow it, by default. if setgroups is set to deny, then it's not possible for me to drop any groups, and therefore allowing me to map supplemental groups wouldn't be a problem right ? -mike --wtjvnLv0o8UUzur2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWAc2PAAoJEEFjO5/oN/WBFlIQAKXKIvCSgIHkKyQ3nnNZRG8Z 8qtEmmaJVhUJjC9N638MRBAPnscCb7EV11vyW15NSPjGLQPW3a2evwHtO/3w+hZt /nDQWgEPQIBhfpHNJLaPLPowUUG23Wyzzbpa2LSmSELWLWbfzUqenKvx4wlmm+XS e1KDhRPwRcO5zvEWwHRi+fiSQQ7zo2Sven0+xuTzm9Zp132RonB3PI97KiWgr/Sx WIQvTpCjttjye6dlyyK9ag+Kb5Pzwv3JMlCgaFubcalkOsMv/Ynzumii6VRQOBeH 8HZr839AmMjm35GuW7lb3RpEK+p66afPHyXwohS4/ZwzRlEIaoGt+Vg7QN40AX0u Vi0SxgAbGiJ/aSxf6V2Ujl0TW3Ct4XdTFiyAA1C+HtCBFQDIrjxLJT4oPAD6a/fz o5NaYMEsTf6OPhUiLZR1GI2Kl16CPVkPX/uGw6YkI1CpRWp8VuSFK1Xvox7beNvh Tjhed2tYJ1WKi4eQmdG/kiGtmcyi9Hxb8U3oUJ5Pzn8QyxyVmgvNKfWdRPNel3Lu JoFbuc9MtiBFt4SMa8ZJaW6mdk0qstG8y9WHSTcwPV+G54tX3HPchh8SYqLWrco7 RV/b5s2SmYjW/ivt53jbAJwAzgFgw6wxFAMxEwjCpKlluL3iBJntn1HRgY+ZoKBO h2yxgI5MBrwnt/zXMA7L =41wf -----END PGP SIGNATURE----- --wtjvnLv0o8UUzur2--