Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932139AbbHFIXF (ORCPT ); Thu, 6 Aug 2015 04:23:05 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:36631 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754524AbbHFIWC (ORCPT ); Thu, 6 Aug 2015 04:22:02 -0400 From: David Herrmann To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , Daniel Mack , Djalal Harouni , David Herrmann Subject: [PATCH 6/9] kdbus: inline privilege checks Date: Thu, 6 Aug 2015 10:21:25 +0200 Message-Id: <1438849288-18112-7-git-send-email-dh.herrmann@gmail.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1438849288-18112-1-git-send-email-dh.herrmann@gmail.com> References: <1438849288-18112-1-git-send-email-dh.herrmann@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3478 Lines: 107 Instead of caching privilege information in 'kdbus_handle' (and thus increasing the size of each handle by 8 byte), perform privilege checks on the cached creds in file->f_cred inline. None of the functions that need those checks is a fast path (in fact, it's just EP_MAKE that needs it right now), so there's no need to cache the data. If more functions need this check later on, we should turn it into a small static helper. Signed-off-by: David Herrmann --- ipc/kdbus/handle.c | 34 +++++++++++----------------------- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/ipc/kdbus/handle.c b/ipc/kdbus/handle.c index a93c385..4d41ecf 100644 --- a/ipc/kdbus/handle.c +++ b/ipc/kdbus/handle.c @@ -264,7 +264,6 @@ enum kdbus_handle_type { * @bus_owner: bus this handle owns * @ep_owner: endpoint this handle owns * @conn: connection this handle owns - * @privileged: Flag to mark a handle as privileged */ struct kdbus_handle { struct mutex lock; @@ -275,8 +274,6 @@ struct kdbus_handle { struct kdbus_ep *ep_owner; struct kdbus_conn *conn; }; - - bool privileged:1; }; static int kdbus_handle_open(struct inode *inode, struct file *file) @@ -298,23 +295,6 @@ static int kdbus_handle_open(struct inode *inode, struct file *file) mutex_init(&handle->lock); handle->type = KDBUS_HANDLE_NONE; - if (node->type == KDBUS_NODE_ENDPOINT) { - struct kdbus_ep *ep = kdbus_ep_from_node(node); - struct kdbus_bus *bus = ep->bus; - - /* - * A connection is privileged if it is opened on an endpoint - * without custom policy and either: - * * the user has CAP_IPC_OWNER in the domain user namespace - * or - * * the callers euid matches the uid of the bus creator - */ - if (!ep->user && - (ns_capable(bus->domain->user_namespace, CAP_IPC_OWNER) || - uid_eq(file->f_cred->euid, bus->node.uid))) - handle->privileged = true; - } - file->private_data = handle; ret = 0; @@ -406,6 +386,7 @@ static long kdbus_handle_ioctl_ep(struct file *file, unsigned int cmd, struct kdbus_handle *handle = file->private_data; struct kdbus_node *node = file_inode(file)->i_private; struct kdbus_ep *ep, *file_ep = kdbus_ep_from_node(node); + struct kdbus_bus *bus = file_ep->bus; struct kdbus_conn *conn; int ret = 0; @@ -413,14 +394,20 @@ static long kdbus_handle_ioctl_ep(struct file *file, unsigned int cmd, return -ESHUTDOWN; switch (cmd) { - case KDBUS_CMD_ENDPOINT_MAKE: + case KDBUS_CMD_ENDPOINT_MAKE: { + bool priv; + + priv = uid_eq(file->f_cred->euid, bus->node.uid) || + file_ns_capable(file, bus->domain->user_namespace, + CAP_IPC_OWNER); + /* creating custom endpoints is a privileged operation */ - if (!handle->privileged) { + if (file_ep->user || !priv) { ret = -EPERM; break; } - ep = kdbus_cmd_ep_make(file_ep->bus, buf); + ep = kdbus_cmd_ep_make(bus, buf); if (IS_ERR_OR_NULL(ep)) { ret = PTR_ERR_OR_ZERO(ep); break; @@ -429,6 +416,7 @@ static long kdbus_handle_ioctl_ep(struct file *file, unsigned int cmd, handle->ep_owner = ep; ret = KDBUS_HANDLE_EP_OWNER; break; + } case KDBUS_CMD_HELLO: conn = kdbus_cmd_hello(file_ep, file, buf); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/