[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140313142755.GC18914@redhat.com>
Date: Thu, 13 Mar 2014 10:27:55 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Simo Sorce <ssorce@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
cgroups@...r.kernel.org,
Network Development <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>, Tejun Heo <tj@...nel.org>,
jkaluza@...hat.com, lpoetter@...hat.com, kay@...hat.com
Subject: Re: [PATCH 2/2] net: Implement SO_PEERCGROUP
On Wed, Mar 12, 2014 at 07:12:25PM -0700, Andy Lutomirski wrote:
[..]
> >> Can you give a realistic example?
> >>
> >> I could say that I'd like to disclose information to processes based
> >> on their rlimits at the time they connected, but I don't think that
> >> would carry much weight.
> >
> > We want to be able to show different user's list from SSSD based on the
> > docker container that is asking for it.
> >
> > This works by having libnsss_sss.so from the containerized application
> > connect to an SSSD daemon running on the host or in another container.
> >
> > The only way to distinguish between containers "from the outside" is to
> > lookup the cgroup of the requesting process. It has a unique container
> > ID, and can therefore be mapped to the appropriate policy that will let
> > us decide which 'user domain' to serve to the container.
> >
>
> I can think of at least three other ways to do this.
>
> 1. Fix Docker to use user namespaces and use the uid of the requesting
> process via SCM_CREDENTIALS.
Using user namespaces sounds like the right way to do it (atleast
conceptually). But I think hurdle here is that people are not convinced
yet that user namespaces are secure and work well. IOW, some people
don't seem to think that user namespaces are ready yet.
I guess that's the reason people are looking for other ways to
achieve their goal.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists