From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751337AbcETRmI (ORCPT ); Fri, 20 May 2016 13:42:08 -0400 Received: from resqmta-po-03v.sys.comcast.net ([96.114.154.162]:47225 "EHLO resqmta-po-03v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbcETRmG (ORCPT ); Fri, 20 May 2016 13:42:06 -0400 Date: Fri, 20 May 2016 10:33:53 -0700 From: "W. Trevor King" To: Tejun Heo Cc: James Bottomley , Aleksa Sarai , Li Zefan , Johannes Weiner , Aleksa Sarai , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, dev@opencontainers.org Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces Message-ID: <20160520173353.GB26350@odin.tremily.us> References: <1463196000-13900-1-git-send-email-asarai@suse.de> <573F23D0.2030500@suse.de> <20160520152244.GB5632@htj.duckdns.org> <1463758258.8091.3.camel@HansenPartnership.com> <20160520160352.GC5632@htj.duckdns.org> <1463760550.8091.13.camel@HansenPartnership.com> <20160520161759.GD5632@htj.duckdns.org> <1463761509.8091.19.camel@HansenPartnership.com> <20160520165326.GE5632@htj.duckdns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <20160520165326.GE5632@htj.duckdns.org> OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8; url=http://tremily.us/pubkey.txt User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm just chipping in from the peanut gallery, so sorry if this misses some earlier discussion. On Fri, May 20, 2016 at 12:53:26PM -0400, Tejun Heo wrote: > Why does an unpriv NS need to have cgroup delegated to it without > cooperation from cgroup manager? If for resource control, I'm > pretty sure we don't want to allow that without explicit cooperation > from the enclosing scope. A useful analogy is renice(1), which allows users to manage the way their allocated resources are distributed among their processes. A system where a sysadmin has to explicitly grant users permission to use renice seems overly restrictive, as does a system where a sysadmin has to explicitly grant users permission to use cgroups to manage their resources. At that level, the only different is probably that adjusting niceness doesn't consume additional system resources, while creating a new cgroup does, and sysadmins might want to protect themselves from having users create zillions of cgroups. On the other hand, sysadmins who do want to grant this power can automatically put users in their own cgroup with adjusted POSIX permissions at login time (e.g. =E2=80=9CHi Alice, here's your own cgroup to manage as you see fit. Hi Bob, =E2=80=A6=E2=80=9D). But having a way to s= ay =E2=80=9CI'm fine with users creating their own cgroup namespaces and sub-cgroups=E2=80= =9D is easier. And making it opt-out (=E2=80=9CI'm *not* fine with users creat= ing their own=E2=80=A6=E2=80=9D) is even easier, and the choice between opt-in = and opt-out probably depends on how expensive cgroups are. Cheers, Trevor --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJXP0p/AAoJEAPqygegUbGssLIQAIsBN238C1fyMpNQjb6nDTC4 YR1jj92lx9jWwbW4ZoMlEpZ+pD6q7nycIG7+Sbj8HFszjZGuFkDOe5Fl/sqQoDwL oKV4MljZf9Wg8HSyzN2ihuBXoxeQ3dcCWei4hlkBHOE/vp9rP2Y8cAZo6k2gCN58 cy2o/EAiXJmMbQctmpKXEJPSJ6AbK+HA459wJ5yLsHgbMNzpFBZ01qicTLUK8SBg nmfKSef8shsF40y/YZFiyixfMpLxtgXaYmtryaoJwFNh/9NAx5RzvMMRZGXtMcKF /7SIzd59dT52yhWC1t3j7A+zaQRgJ5HgjF0ZgC99lDpPKnQYvHxcjPu6ugrgQOQd voDN50t1jR2LO3fDan1mIFtKBzn1AO1P5wtULL+3Ai+sLX86bpQcFQmfuMb5u7JB 7FW6HWQkZgz92l29Jq8elMaPC2Vk2NPh9j+bdpRSS611Umtyrf5rob049rmuHzBR m3OENipP7DOfnBKf94g6b5ZRGyfYCQBiKMgND4gNAY9z9daxpCv00kHuaw02EeAD jyaQY2moQ5hwzsUtLzvP8W1h8n89qgfz4SoO1xHcVVM5NwEnyEMo6lZ8bt3KT2vj fk27UtgW90/vWhrzwMkGGR1QvmiNW52c7izClJRAZ3gvhXfuedj6h7YZL7Tf1F3H XLWZOYEOqGE4s/xMzR59 =/tO8 -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd--