Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4766306imm; Fri, 18 May 2018 10:16:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo4CuYB675yc6Im/KgKHB7bNDfVBJChbUQwe+HMYgzGXLOvi8l3CsqtJMJeHP7JWvLrajR3 X-Received: by 2002:a63:7a5a:: with SMTP id j26-v6mr322103pgn.421.1526663766580; Fri, 18 May 2018 10:16:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526663766; cv=none; d=google.com; s=arc-20160816; b=Z8+sVZPKhpVZMhISsvVYAiFTc23UkVS3a5Bso/SlGMsjLC5nF1Qg541ihSGmkISb6N ZTgrmorSIvWF3wCwE7Q6eFmIIqsKD2FVpsVGM2fUE74nwq4KIxsE9aUz4gkE3qxX/Jn7 gsrRDQq2H6TYptkwpjwbo9QbrKrQWJqgxhOBcam18FxJdlQyRNvWTSkNPtCeFkEwD1b0 E9zO/kKXFE2P2KRgS8XfeUFg4U/eOTybRbOsgaSNMqDnmmM6RkvVNXME1b3KaA6AlOBd Z7Nb8FAJ86/eqscxMPxpjszIy5+xhO8SwojTenfN67UznZD7xagsn5usRJq/Kld6VFqz q/Uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=psqXTlNCYMUuvDI7knMIJnx6ZWBd9uMawcn4lPh9d2Y=; b=A8t41crNeSBT9qrLPiQxQm/XKvEg4eYvJaeRJ+CIWKLAJ339zT1SvkCZzZ3GTBlosy ipF/a+TU4TrjDe5pKfc9F1WoIBtLjsWZw7rWKWi560UryVFAB37VK+fWmBp7yxQlNSXB cMKKwRj+/Q+L7B6EMFAQFF3sDZldr29HMxTM0szft8RFQZ4HSE0rKNFvu83u/00XCMF2 mqWE6UjdKimifrbDsuISQJvs7NUOsHXIJvSosbk2AxH0np0jWOVQZO0xkkcKk6EPrdZJ ck9z8pMwx9EvxgUApnIj5ktCJL07z/z+unbk5JKP4ypN1f1svWbbGd67CYp4SKAF8L4C peKQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3-v6si8164889plb.2.2018.05.18.10.15.51; Fri, 18 May 2018 10:16:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751952AbeERROG (ORCPT + 99 others); Fri, 18 May 2018 13:14:06 -0400 Received: from namei.org ([65.99.196.166]:36322 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbeERROD (ORCPT ); Fri, 18 May 2018 13:14:03 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id w4IHDba8029580; Fri, 18 May 2018 17:13:37 GMT Date: Sat, 19 May 2018 03:13:37 +1000 (AEST) From: James Morris To: "Eric W. Biederman" cc: Casey Schaufler , Mimi Zohar , linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, David Howells , "Luis R . Rodriguez" , kexec@lists.infradead.org, Andres Rodriguez , Greg Kroah-Hartman , Ard Biesheuvel , Kees Cook Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper In-Reply-To: <87y3ghhbws.fsf@xmission.com> Message-ID: References: <1526568530-9144-1-git-send-email-zohar@linux.vnet.ibm.com> <1526568530-9144-4-git-send-email-zohar@linux.vnet.ibm.com> <74c096ca-1ad1-799e-df3d-7b1b099333a7@schaufler-ca.com> <87y3ghhbws.fsf@xmission.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 17 May 2018, Eric W. Biederman wrote: > Nacked-by: "Eric W. Biederman" > > Nack on this sharing nonsense. These two interfaces do not share any > code in their implementations other than the if statement to distinguish > between the two cases. Hmm, it's not even doing that. There's already an if(!file && read_id == X) { } check and this is another one being added. > If we want comprehensible and maintainable code in the security modules > we need to split these two pieces of functionality apart. All ima_read is doing in both the old and new case is checking if there's no file then if it's a certain operation, returning an error. To echo Eric and Casey's suggestions, how about changing the name of the hook to security_kernel_read_data() ? Then ima_read_file() can be changed to ima_read_data(), and then instead of two if (!file && read_id == X) checks, have: if (!file) { switch (read_id) { } } -- James Morris