From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753175AbcGUPCo (ORCPT ); Thu, 21 Jul 2016 11:02:44 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35873 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753119AbcGUPCl (ORCPT ); Thu, 21 Jul 2016 11:02:41 -0400 Date: Thu, 21 Jul 2016 11:01:35 -0400 From: Tejun Heo To: Aleksa Sarai Cc: "Serge E. Hallyn" , Greg Kroah-Hartman , Li Zefan , Johannes Weiner , "Serge E. Hallyn" , Aditya Kali , Chris Wilson , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Christian Brauner , dev@opencontainers.org, James Bottomley Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Message-ID: <20160721150135.GD22680@htj.duckdns.org> References: <20160718161816.13040-1-asarai@suse.de> <20160718161816.13040-4-asarai@suse.de> <20160720155147.GG4574@htj.duckdns.org> <6e975d80-4077-fb8b-ec84-708e37c8e149@suse.de> <20160720230228.GA19588@mtj.duckdns.org> <982fcf3a-3685-9bd7-dd95-7bff255c9421@suse.de> <20160720231949.GB19588@mtj.duckdns.org> <379e5b13-29d4-ca75-1935-0a64f3db8d27@suse.de> <20160721143330.GA5751@mail.hallyn.com> <2dc90947-cee7-90a9-3e60-4ca7c0de29d3@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2dc90947-cee7-90a9-3e60-4ca7c0de29d3@suse.de> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Aleksa. On Fri, Jul 22, 2016 at 12:37:42AM +1000, Aleksa Sarai wrote: > > Ths is of course solvable using something like libpam-cgfs or > > libpam-cgm (and others). Since this sounds like a question of > > policy, not mechanism, userspace seems like the right place. Is > > there a downside to that (or, as Tejun put it, "delegating explicitly")? > > Having a PAM module requires getting an administrator to install the PAM > module (and also presumably audit it, not to mention convincing them that > your requirement to use containers are significant enough for them to do any > work). It's the same problem IMO. I understand that LXC allows you to do > this, but it requires that you get an administrator to *install* and support > LXC (as well as the shadow-utils setuid binaries too). There are cases where > you don't have the freedom to do that, and also "just get someone to give > you privileges temporarily" is again punting on the problem. The administrator has to install a new kernel to get this feature from kernel side too. I don't think "to bypass admin" is a strong argument for a new kernel feature especially when it's likely to cause subtle issues as in this case. Thanks. -- tejun