Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3302816rwb; Mon, 15 Aug 2022 23:41:16 -0700 (PDT) X-Google-Smtp-Source: AA6agR6eBz0CQUJcQV0CQfFfBNK3SL7J7aB8TJVScVzihT5uXLoiTftautBDucMW5cOM1nIUG1ki X-Received: by 2002:a05:6402:4517:b0:443:7fe1:2d60 with SMTP id ez23-20020a056402451700b004437fe12d60mr11593868edb.133.1660632076426; Mon, 15 Aug 2022 23:41:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660632076; cv=none; d=google.com; s=arc-20160816; b=amF978jKVTRJX/RVZUE4RKJ3zZxRqADrYhyXqTT9VUR0UqBSFFzX4IalR0Op9+iLEy 2eEZ7T8yxAf89IRIE2jtSGjyiLFRj1vh5xDTIAfg4zq7lKW4JkHcyoQUOENTgVo1KV/Q 1ZfAER1WpgP8O7/UUWaFxFHMEm0HoDqgnBBtz/WXZuJyIlctE8UXq3Yo2qDnMT0Iy5H/ o9B4Cu+7lyWfec8qhuYstV9vMfLp12wpoAyb4Kc3GDIgNE9a4virNHo3V8QLtwwcRvzA KeirIgjHxGxgVDOed2X71VBdC0XiRnafx44GHjGtV/P2Q0BJq1Xa3ls3Hm4te9M+Ygvr PHSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=sjHa9icqRlJ0JksO3F6ZvE7i15gfikQ5o3Vy7JFxppE=; b=kBhqueP/W9V6ute2RljK3ajmIQvoOJNFDOvnFSNOXee5a21CbKiRxCDnYLw/ug6cRc emgojedp93DFwnXFm3IBj3KGAKQZMCsL0qMn/G64XBCs7dy2qeNUYw1spD9HgocSFvsH ntO7qXs2MFrenOvk/QYm463K6ZnYTsyO2JjXNsNa4SCg8nyfZj9UTqpxFZlaehBQpqkg WG8y7/oUdmJM3xhLOINIgYGxkjxxakHQgmRQRYk8f2efM9Wvu+WuHLQtI07zL9JTZcV9 Mag88NBkx2TODfj8AQxHHSW01NITTdVmv1tNd2+D6V7OQe8nd/E2JHfVYpFsoFl2AwFA ntaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=h0YbD3es; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dx6-20020a170906a84600b0072b4cba9671si8020418ejb.186.2022.08.15.23.40.50; Mon, 15 Aug 2022 23:41:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=h0YbD3es; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230081AbiHPGZw (ORCPT + 99 others); Tue, 16 Aug 2022 02:25:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229781AbiHPGZg (ORCPT ); Tue, 16 Aug 2022 02:25:36 -0400 Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8967F13674B for ; Mon, 15 Aug 2022 17:31:20 -0700 (PDT) Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-10ea30a098bso10004592fac.8 for ; Mon, 15 Aug 2022 17:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=sjHa9icqRlJ0JksO3F6ZvE7i15gfikQ5o3Vy7JFxppE=; b=h0YbD3es2uiuXm+iZMywYsWMiom4/q54qBleqHYw3O9z1DwQ1PDlGF7Oyud718lg1x v39v3Ab3qyz/iA8AwkK9PidS3HjQqrJLfMvtJobFOkfLKkYQp8LgYozNCFwKGTgWzHV6 AU4FLhPWOZnSok4kEb/PWbb9inD8DI/xUupOvz+CO+iQMAQsqVvdyLd58vbCGY2aHGGl ijXXD3GpqM2Z7MgXjowUbLaAvK8lhnjeEBWxfx/MYLlQnYEJNqEw9wqhzl9S7bEvgjXa AdfC04QQAFuTXNxf5uQWCVF4h8ix74FubFDHSZ5Q7SHRJ6mqpL+dnF17CUYYUn8Gs5zG fskg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=sjHa9icqRlJ0JksO3F6ZvE7i15gfikQ5o3Vy7JFxppE=; b=E1CrYT0OAQWcwEEMlRisWKLgOEQ5UgrrmUoEATBbNEhyNVy0GiZmnUrlkIcS7Ot5mx c7GWVz5cqVBTKrQi5hZBtDw658lrnink9wBcxmM0GrJ/P/n5njDL/hFUDrKk3ppgf/cH 4IfNz2ER500fJiT/wwCtdgjhOV4v+Grir1DgDbfMGhjLzbUZOo3kViJlfUo6whNt5fJb +EKr/wNDcETML80+XUuu4UeAsLPk20WiKKxe6H4WtQOl5UY4HrHAYBsIBZgmuPIgte1j X80UXEfIVyl/nLxJDNC/HUc00SjBCH/LR0NnxiPGXvf2sV7cnFu6D1BuR1W2adXPSCa6 2viQ== X-Gm-Message-State: ACgBeo00I/ELMP1oGnwr/tUU+70AkntvimE0IT+syZ8y3Lspt0BQKiTk hC4Fyd8jNhmscoOcd/CyIqfEgXczJ2eAWACVtlgE X-Received: by 2002:a05:6870:b41e:b0:116:5dc7:192a with SMTP id x30-20020a056870b41e00b001165dc7192amr8115012oap.136.1660609879901; Mon, 15 Aug 2022 17:31:19 -0700 (PDT) MIME-Version: 1.0 References: <2d8159cec4392029dabfc39b55ac5fbd0faa9fbd.1659996830.git.rgb@redhat.com> In-Reply-To: <2d8159cec4392029dabfc39b55ac5fbd0faa9fbd.1659996830.git.rgb@redhat.com> From: Paul Moore Date: Mon, 15 Aug 2022 20:31:09 -0400 Message-ID: Subject: Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, Eric Paris , Steve Grubb , Jan Kara , Amir Goldstein Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 9, 2022 at 1:23 PM Richard Guy Briggs wrote: > > Currently the only type of fanotify info that is defined is an audit > rule number, but convert it to hex encoding to future-proof the field. > > Sample record: > type=FANOTIFY msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=3F > > Suggested-by: Paul Moore > Signed-off-by: Richard Guy Briggs > --- > kernel/auditsc.c | 28 +++++++++++++++++++++------- > 1 file changed, 21 insertions(+), 7 deletions(-) This needs to be squashed with patch 3/4; it's a user visible change so we don't want someone backporting 3/4 without 4/4, especially when it is part of the same patchset. > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index f000fec52360..0f747015c577 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -2908,22 +2908,36 @@ void __audit_fanotify(u32 response, size_t len, char *buf) > > if (!(len && buf)) { > audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > - "resp=%u fan_type=0 fan_info=?", response); > + "resp=%u fan_type=0 fan_info=3F", response); /* "?" */ Please drop the trailing comment, it's not necessary and it makes the code messier. > return; > } > while (c >= sizeof(struct fanotify_response_info_header)) { > + struct audit_context *ctx = audit_context(); > + struct audit_buffer *ab; > + > friar = (struct fanotify_response_info_audit_rule *)buf; > switch (friar->hdr.type) { > case FAN_RESPONSE_INFO_AUDIT_RULE: > if (friar->hdr.len < sizeof(*friar)) { > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > - "resp=%u fan_type=%u fan_info=(incomplete)", > - response, friar->hdr.type); > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > + if (ab) { > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > + response, friar->hdr.type); > +#define INCOMPLETE "(incomplete)" > + audit_log_n_hex(ab, INCOMPLETE, sizeof(INCOMPLETE)); Is the distinction between "?" and "(incomplete)" really that important? I'm not going to go digging through all of the audit_log_format() callers to check, but I believe there is precedence for using "?" not only for when a value is missing, but when it is bogus as well. If we are really going to use "(incomplete)" here, let's do a better job than defining a macro mid-function and only using it in one other place - the line immediately below the definition. This is both ugly and a little silly (especially when one considers that the macro name is almost exactly the same as the string it replaces. If we must use "(incomplete)" here, just ditch the macro; any conceptual arguments about macros vs literals is largely rendered moot since there is only one user. > + audit_log_end(ab); > + } > return; > } > - audit_log(audit_context(), GFP_KERNEL, AUDIT_FANOTIFY, > - "resp=%u fan_type=%u fan_info=%u", > - response, friar->hdr.type, friar->audit_rule); > + ab = audit_log_start(ctx, GFP_KERNEL, AUDIT_FANOTIFY); > + if (ab) { > + audit_log_format(ab, "resp=%u fan_type=%u fan_info=", > + response, friar->hdr.type); > + audit_log_n_hex(ab, (char *)&friar->audit_rule, > + sizeof(friar->audit_rule)); > + audit_log_end(ab); > + > + } > } > c -= friar->hdr.len; > ib += friar->hdr.len; > -- > 2.27.0 -- paul-moore.com