From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755133AbaCMUSI (ORCPT ); Thu, 13 Mar 2014 16:18:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28926 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753085AbaCMUSE (ORCPT ); Thu, 13 Mar 2014 16:18:04 -0400 Date: Thu, 13 Mar 2014 16:17:55 -0400 From: Vivek Goyal To: Andy Lutomirski Cc: Simo Sorce , "linux-kernel@vger.kernel.org" , cgroups@vger.kernel.org, Network Development , "David S. Miller" , Tejun Heo , jkaluza@redhat.com, lpoetter@redhat.com, kay@redhat.com Subject: Re: [PATCH 2/2] net: Implement SO_PEERCGROUP Message-ID: <20140313201755.GO18914@redhat.com> References: <1394673476.32465.215.camel@willson.li.ssimo.org> <1394675038.32465.223.camel@willson.li.ssimo.org> <1394733077.32465.243.camel@willson.li.ssimo.org> <20140313195349.GM18914@redhat.com> <20140313200649.GN18914@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140313200649.GN18914@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 13, 2014 at 04:06:49PM -0400, Vivek Goyal wrote: > On Thu, Mar 13, 2014 at 12:58:14PM -0700, Andy Lutomirski wrote: > > On Thu, Mar 13, 2014 at 12:53 PM, Vivek Goyal wrote: > > > On Thu, Mar 13, 2014 at 10:55:16AM -0700, Andy Lutomirski wrote: > > > > > > [..] > > >> >> 2. Docker is a container system, so use the "container" (aka > > >> >> namespace) APIs. There are probably several clever things that could > > >> >> be done with /proc//ns. > > >> > > > >> > pid is racy, if it weren't I would simply go straight > > >> > to /proc//cgroups ... > > >> > > >> How about: > > >> > > >> open("/proc/self/ns/ipc", O_RDONLY); > > >> send the result over SCM_RIGHTS? > > > > > > As I don't know I will ask. So what will server now do with this file > > > descriptor of client's ipc namespace. > > > > > > IOW, what information/identifier does it contain which can be > > > used to map to pre-configrued per container/per namespace policies. > > > > Inode number, which will match that assigned to the container at runtime. > > > > But what would I do with this inode number. I am assuming this is > generated dynamically when respective namespace was created. To me > this is like assigning a pid dynamically and one does not create > policies in user space based on pid. Similarly I will not be able > to create policies based on an inode number which is generated > dynamically. > > For it to be useful, it should map to something more static which > user space understands. Or could we do following. open("/proc/self/cgroup", O_RDONLY); send the result over SCM_RIGHTS But this requires client modification. Thanks Vivek