On Saturday, August 22, 2015 2:07 AM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Aug 14, 2015 at 08:52:05AM -0400, kaike.wan@xxxxxxxxx wrote: > >> Some tests with namespace have been performed: >> 1. An unprivileged user cannot bind to the RDMA_NL_GROUP_LS multicast >> group; >> 2. An unprivileged user cannot create a new network namespace. However, >> it can create a new user namespace together with a new network >> namespace by using clone() with CLONE_NEWUSER | CLONE_NEWNET flags; >> 3. In the user and network namespaces created by an unprivileged user, >> the user can be mapped into root and thus be able to bind to the >> RDMA_NL_GROUP_LS multicast group. However, it can neither send >> requests to the kernel RDMA netlink code nor receive requests from >> it. This is because kernel RDMA netlink code associates itself with >> the init_net network namespace, which in turn associates itself with >> init_user_ns namespace. > > Haggie, how does this coverage match your expectations with your > namespace series? It sounds good. Our thinking was that the network namespace assigns netdevs to namespaces, and we don't want to assign an entire IB device to a namespace, so it isn't suitable for restricting applications that deal with IB directly. RDMA CM already used IP addressing so it is was suitable to be changed to work only with the devices in a process's network namespace. We also discussed creating a cgroup for RDMA later on, that could make sure a container can only use certain P_Keys, for applications that don't use RDMA CM. Such a cgroup could also be used to limit the SA queries a process can issue. Haggai -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
