Received: by 10.192.165.148 with SMTP id m20csp431269imm; Fri, 20 Apr 2018 09:02:40 -0700 (PDT) X-Google-Smtp-Source: AIpwx48P7YEoLCYCrjjrcdx7tPEstHf3joqSNqOniVktrQg+ACQehaYJk8+aX39ombDRuea+UNcv X-Received: by 2002:a17:902:8e8c:: with SMTP id bg12-v6mr10697662plb.295.1524240160483; Fri, 20 Apr 2018 09:02:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524240160; cv=none; d=google.com; s=arc-20160816; b=MWhkHM+12m+0L6GeH3Ab+GwYIukyMIM2BAvWtiHJbLrcI+iJGKo42awarZBcy5jYjZ tyogieNI/iJQ0ByFa3nv1WxvL7YqgniYUct62Fzwq0DGeNHkBmlMep0UrsczRQ5EfNfb Z+o9yyO8B1DK5qxRuSnAYeNyqbDLVmOXzv4pIO/kP5eKqImtAjKkVw+A1D+mX2JjL9UZ ZIhzz7W03Pi+0/ww4rc06iVktXbCrieoAbIg9li3ypnE8tC3Ao7aRAh2LJH4dx80IlhX 71nvL7pCvlDcTfhfGdoyZvWIqCvBc9tPtRVynT+QpCxVSm6VFXxNyHYNuATL7K7ru3mC fd7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=S7syKFhyNuCbDaE7jByejGNDZvTseMfN00g+8E1yiVs=; b=dRW6DzFnZwOaFvakbYh4uNtthBSMHIax0sIdYHE1kVXrlt43HAPMDtrqAcgXSd9HX0 yl6/SePhn/XIBv2YH+nsptATmU+Bw6fVdm5vN0jBI+ZmECZyVVa98ehoGurYoD1LuX2b tT5G7uHlM3VJKbsxOZA/uZbiJiufzxl/3xVIF8W6XE0Hc9AfsdO+BPFTxDH413tWbmhM grzCQbL1NaSOHE+c+qVU3RDcmfjT7MexvhwC3LuI3ca1Fu0f6dknGJYi47Xt5K8XZMT0 ho45OCBMe9p7Se8kb7BAYG0s3UVDcuTyf9k07a22jtGmIpmPb2O8BwjuFJUUR5vE2DjP /Ykg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=XQzjDINS; 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 4-v6si5951730pld.371.2018.04.20.09.02.25; Fri, 20 Apr 2018 09:02:40 -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; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=XQzjDINS; 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 S1756016AbeDTP6d (ORCPT + 99 others); Fri, 20 Apr 2018 11:58:33 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:33068 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755850AbeDTP6b (ORCPT ); Fri, 20 Apr 2018 11:58:31 -0400 Received: by mail-lf0-f68.google.com with SMTP id d79-v6so5890079lfd.0 for ; Fri, 20 Apr 2018 08:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S7syKFhyNuCbDaE7jByejGNDZvTseMfN00g+8E1yiVs=; b=XQzjDINSNL+/TkOALaMdZeKZIf76JGryZ9yB0/XBoYauKjgfTUTGAsiF4C54Wlyc1W rz74TzPFGOREiZXGKhdUPwBsMGSGlGKpBkV48WBZp70Kgvqmw6FFoPlw0BKHMujmQ2Xk LJzXJAcLj8UIAk2bAqHcr/UvfoTFlZNoDK0FjBnLkwKu6DaOH+bFgzYve0nLdfNPSECF X3ADNG5tB56ZsW/wMcx4dKjdkACBXJN9h87to42AjUZrDmk6mYUyy1Fckbjj+rv7nLfT ZdH4IlszavVid4/yalnjA5WUFt432xYtwDSIwP/wp/poKKbKyAt4nk8TDv+BqSgN548C XccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S7syKFhyNuCbDaE7jByejGNDZvTseMfN00g+8E1yiVs=; b=jxDXDovp4FeQKEqdzBRY4PLAT+h4/XNst7nhlnhfkYUMOjQC9rcT+NYTrPuaXWV5s3 ycY0+1BH9v7DGOQJZ3VsYUWYwGwz7tst7Wk6DgqZawMfsnQWw3KnyeOJN6cXel7u4Uv/ G9aRt3t/Culw+//SEh9KKc8aeCwwzMHbMFD3QOHStQpgG/8snAwbe4d0G2THm8kZfkuQ 15y89+m59/y7bW9w0AaRB0czOVwcmJTJACvvOV8s71sKZRisOJUWT/rMdZU0E2sxFJKL dUbkAwRQqjx6a5Om7JXYNkOtDs2mklWn30pfuRLiwIMzFe2kuBIugUqseyQgPWeshb+i WYkQ== X-Gm-Message-State: ALQs6tC7R3rnCrwIf8hqrEd4kwNLrm7WDkxQ1/QyVj83bprGG5IBrfpy N9dUkWz3TIF1seAPPOOq2lnLZ5jYBK48XZfoxSAH X-Received: by 2002:a19:8e8e:: with SMTP id a14-v6mr3255963lfl.145.1524239909574; Fri, 20 Apr 2018 08:58:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:a5c3:0:0:0:0:0 with HTTP; Fri, 20 Apr 2018 08:58:28 -0700 (PDT) X-Originating-IP: [108.20.156.165] In-Reply-To: <20180420134651.3badjswsokqs7hex@madcap2.tricolour.ca> References: <08bd08ee9bc70f6e98b9e298ba6a2c0f4dcadb4b.1523372093.git.rgb@redhat.com> <20180420134651.3badjswsokqs7hex@madcap2.tricolour.ca> From: Paul Moore Date: Fri, 20 Apr 2018 11:58:28 -0400 Message-ID: Subject: Re: [PATCH ghak80 V1] audit: add syscall information to FEATURE_CHANGE records To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , Eric Paris , Steve Grubb Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 9:46 AM, Richard Guy Briggs wrote: > On 2018-04-17 18:06, Paul Moore wrote: >> On Wed, Apr 11, 2018 at 8:46 AM, Richard Guy Briggs wrote: >> > Tie syscall information to FEATURE_CHANGE calls since it is a result of >> > user action. >> > >> > See: https://github.com/linux-audit/audit-kernel/issues/80 >> > >> > Signed-off-by: Richard Guy Briggs >> > --- >> > kernel/audit.c | 5 ++--- >> > 1 file changed, 2 insertions(+), 3 deletions(-) >> > >> > diff --git a/kernel/audit.c b/kernel/audit.c >> > index 8da24ef..23f125b 100644 >> > --- a/kernel/audit.c >> > +++ b/kernel/audit.c >> > @@ -1103,10 +1103,9 @@ static void audit_log_feature_change(int which, u32 old_feature, u32 new_feature >> > { >> > struct audit_buffer *ab; >> > >> > - if (audit_enabled == AUDIT_OFF) >> > + if (!audit_enabled) >> >> Sooo, this is an unrelated style change, why? Looking at the rest of >> kernel/audit.c we seem to use a mix of "(!x)" and "(x == 0/CONST)" so >> why are you adding noise to this patch? > > Ok, survey sez 25 instances of audit_enabled used as a boolean vs 7 > instances where it could be used as a boolean where the expression is > made harder to read (in my opinion). I thought it was worth changing to > read the same way most of the other instances I've been reviewing are > written. There are only two where the non-boolean distiction with > AUDIT_LOCKED is required. Thanks for the explanation. While I still believe this patch, and connecting records in general, is the Right Thing To Do, I'm expecting there to be some hate mail on this issue and I would like to keep the patch as small and as straight-to-the-point as possible just so there is little confusion about what is changing. Please respin this without the style change and I'll merge it as soon as I see it. Alternatively, give me the "ok" and I'll merge the patch now and just drop the style change; after all we're talking about one line in a five line patch ;) >> > return; >> > - >> > - ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_FEATURE_CHANGE); >> > + ab = audit_log_start(current->audit_context, GFP_KERNEL, AUDIT_FEATURE_CHANGE); >> >> This is the important part, and the Right Thing To Do. >> >> > if (!ab) >> > return; >> > audit_log_task_info(ab, current); -- paul moore www.paul-moore.com