From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753996AbbIKTBX (ORCPT ); Fri, 11 Sep 2015 15:01:23 -0400 Received: from fr-hpgre-esg-01.alcatel-lucent.com ([135.245.210.22]:59147 "EHLO smtp-fr.alcatel-lucent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753946AbbIKTBU (ORCPT ); Fri, 11 Sep 2015 15:01:20 -0400 Subject: Re: [PATCH 3/3] net/udevns: Netlink module to forward uevent to containers To: "Eric W. Biederman" References: <87si6lvk8z.fsf@x220.int.ebiederm.org> Cc: gregkh@linuxfoundation.org, davem@davemloft.net, linux-kernel@vger.kernel.org, containers@lists.linuxcontainers.org, serge.hallyn@ubuntu.com, stgraber@ubuntu.com From: Michael J Coss X-Enigmail-Draft-Status: N1110 Message-ID: <55F324FB.1070803@alcatel-lucent.com> Date: Fri, 11 Sep 2015 15:01:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87si6lvk8z.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/10/2015 9:05 PM, Eric W. Biederman wrote: > "Michael J. Coss" writes: > >> New generic netlink module to provide an interface with the new >> forwarding interface for uevent. The driver allows a user to >> direct a uevent as read from the kernel to a specific network >> namespace by providing the uevent message, and a target process id. >> The uapi header file provides the message format. > If we can't just pass the message thourgh I don't expect genetlink is a > particularly good interface for this. > > It would be nice if we could open some appropriate thing and the act of > getting a file descriptor ould suppress all of the uevent broadcast > messages in that network namespace. > > Further GENL_ADMIN_PERM is an unfortunate choice for a permission check. > I don't see it as exploitable but I am not certain CAP_SYS_ADMIN is the > best capability to check. Beyond that we probably want to arrange > things so that we can use ns_capable so we can allow containers to hand > off their devices to child containers. > > Implementations that do not allow for containers to nest bother me. > > I've done several different approaches with this. I really just wanted an interface to the kernel function to provide forwarding. The first choice was just a pseudo device that you wrote uevent messages to and that message was forwarded. This is yet another take on that. I'm not sure whether one is better or worse than the other. Thanks for the feedback. -- ---Michael J Coss