lkml.org 
[lkml]   [2014]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/2] net: Implement SO_PEERCGROUP
    From
    Date
    On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
    > On Thu, Mar 13, 2014 at 10:51 AM, Simo Sorce <ssorce@redhat.com> wrote:
    > > On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
    > >> On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce <ssorce@redhat.com> wrote:
    > >> > On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
    > >> >> On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce <ssorce@redhat.com> wrote:
    > >> >> > On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
    > >> >> >> On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce <ssorce@redhat.com> wrote:
    > >> >> >>
    > >> >> >> >
    > >> >> >> > Connection time is all we do and can care about.
    > >> >> >>
    > >> >> >> You have not answered why.
    > >> >> >
    > >> >> > We are going to disclose information to the peer based on policy that
    > >> >> > depends on the cgroup the peer is part of. All we care for is who opened
    > >> >> > the connection, if the peer wants to pass on that information after it
    > >> >> > has obtained it there is nothing we can do, so connection time is all we
    > >> >> > really care about.
    > >> >>
    > >> >> 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.
    > >
    > > This is not practical, I have no control on what UIDs will be used
    > > within a container, and IIRC user namespaces have severe limitations
    > > that may make them unusable in some situations. Forcing the use of user
    > > namespaces on docker to satisfy my use case is not in my power.
    >
    > Except that Docker w/o userns is basically completely insecure unless
    > selinux or apparmor is in use, so this may not matter.
    >
    > >
    > >> 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/<pid>/ns.
    > >
    > > pid is racy, if it weren't I would simply go straight
    > > to /proc/<pid>/cgroups ...
    >
    > How about:
    >
    > open("/proc/self/ns/ipc", O_RDONLY);
    > send the result over SCM_RIGHTS?

    This needs to work with existing clients, existing clients, don't do
    this.

    > >> 3. Given that Docker uses network namespaces, I assume that the socket
    > >> connection between the two sssd instances either comes from Docker
    > >> itself or uses socket inodes. In either case, the same mechanism
    > >> should be usable for authentication.
    > >
    > > It is a unix socket, ie bind mounted on the container filesystem, not
    > > sure network namespaces really come into the picture, and I do not know
    > > of a racefree way of knowing what is the namespace of the peer at
    > > connect time.
    > > Is there a SO_PEER_NAMESPACE option ?
    >
    > So give each container its own unix socket. Problem solved, no?
    >
    > --Andy





    \
     
     \ /
      Last update: 2014-03-13 19:41    [W:3.430 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site