From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757550AbdEWOzB (ORCPT ); Tue, 23 May 2017 10:55:01 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:49543 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S968318AbdEWOy4 (ORCPT ); Tue, 23 May 2017 10:54:56 -0400 X-ME-Sender: Message-Id: <1495551292.2742620.985957224.3FCF254A@webmail.messagingengine.com> From: Colin Walters To: Djalal Harouni , "Eric W. Biederman" Cc: Jeff Layton , David Howells , trondmy@primarydata.com, Miklos Szeredi , linux-nfs@vger.kernel.org, "linux-kernel" , Alexander Viro , Linux FS Devel , "open list:CONTROL GROUP (CGROUP)" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694 Date: Tue, 23 May 2017 10:54:52 -0400 In-Reply-To: References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> <87lgpoww67.fsf@xmission.com> <1495491733.25946.3.camel@redhat.com> <874lwbraxh.fsf@xmission.com> Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > Maybe it depends on the cases, a general approach can be too difficult > to handle especially from the security point. Maybe it is better to > identify what operations need what context, and a userspace > service/proxy can act using kthreadd with the right context... at > least the shift to this model has been done for years now in the > mobile industry. Why not drop the upcall model in favor of having userspace monitor events via a (more efficient) protocol and react to them on its own? It's just generally more flexible and avoids all of those issues like replicating the seccomp configuration, etc. Something like inotify/signalfd could be a precedent around having a read()/poll()able fd. /proc/keys-requests ? Then if you create a new user namespace, and open /proc/keys-requests, the kernel will always write to that instead of calling /sbin/request-key. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Walters Subject: Re: [RFC][PATCH 0/9] Make containers kernel objects Date: Tue, 23 May 2017 10:54:52 -0400 Message-ID: <1495551292.2742620.985957224.3FCF254A@webmail.messagingengine.com> References: <149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk> <87lgpoww67.fsf@xmission.com> <1495491733.25946.3.camel@redhat.com> <874lwbraxh.fsf@xmission.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=x04t/f C4OvRVtz3F3kzRPdc/9jLYOF/dYfohcLgViDc=; b=JWBr89NIHiIXTUue1ai9qL T/t/3jci3TaigXWTfRAxsseCoOhG6+dd+ZX4w2Y0Fxp4OyfYmlHS/QVS7i9jOamS 35bGLtID3wQuHWmhYcNWCdIhYDvJvUOvLyiHqCvxadJLJ2Cli2Teq3aVWsLLKiYR K9tF2fjvh2N2wRTLQTUhefxaW+YemoC4MtkCgyPD8AjsSDDFSnIPbFu13eoTsLiF +QhJal9hc/c6bXIRke5cig9Lcj3ZbLTS/nAxrud6EJiRMqeVx0ZEf9yYrMMi5ivH ESaBBT6lYPeXUJ96QKArGILBcCsuatvgyXSCJAoiBhD3U7VVkyMkXxcpMhrDkRzA == In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Djalal Harouni , "Eric W. Biederman" Cc: Jeff Layton , David Howells , trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org, Miklos Szeredi , linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel , Alexander Viro , Linux FS Devel , "open list:CONTROL GROUP (CGROUP)" On Tue, May 23, 2017, at 10:30 AM, Djalal Harouni wrote: > > Maybe it depends on the cases, a general approach can be too difficult > to handle especially from the security point. Maybe it is better to > identify what operations need what context, and a userspace > service/proxy can act using kthreadd with the right context... at > least the shift to this model has been done for years now in the > mobile industry. Why not drop the upcall model in favor of having userspace monitor events via a (more efficient) protocol and react to them on its own? It's just generally more flexible and avoids all of those issues like replicating the seccomp configuration, etc. Something like inotify/signalfd could be a precedent around having a read()/poll()able fd. /proc/keys-requests ? Then if you create a new user namespace, and open /proc/keys-requests, the kernel will always write to that instead of calling /sbin/request-key. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html