Received: by 2002:a05:6358:4e97:b0:b3:742d:4702 with SMTP id ce23csp3149423rwb; Mon, 15 Aug 2022 19:24:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR5enmpqAEHU32bjqzHWufom8oPmFHcO3RicmAv1sWYk8QZbHBnr/YvD7K/jtw6N7lQae+lQ X-Received: by 2002:a17:907:2c78:b0:730:e952:4104 with SMTP id ib24-20020a1709072c7800b00730e9524104mr12259961ejc.33.1660616685241; Mon, 15 Aug 2022 19:24:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660616685; cv=none; d=google.com; s=arc-20160816; b=igAs1/oNU8Dwghhyeq7JEhsSBadkjoYR9p3xcV4oH9lgnd+JPuLjRvQdoQXNEuLpNs gYSE2sfmJ5VomgN/6nWpe3bc60Mvq8nuv/+pLoyBR9vxzZUUoKigDcjz3bSraAHpO8yr NT292gV74EFja0Rjib4R171+Um+/wuDDLs6qJDkSxoKG5T6vVjeE7wcl/XbCkvHvD/mX zjeLk4Rwc1Lel17yt7if7jcS+HE9dlwtzPVnTK2EST4NOy5u+DTHKY0U5oPi2h7lxfLs trcdgzW3rZ+j1lFYciybE2j7TOfL7DFR33cQ8bh3DOM0tKHZUEj3f7/Nv77CxLjr+G6t 13OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from:dkim-signature; bh=SjOJ2ej9e5ff+yIWDnHyj8tdGUgmaChLo0SiD6yuEcY=; b=I8tBtSc/BwEjooW8qXQHwzXgLaIbVXAj4q5Jqah04YsaHaziJjVx15AObs46Vi8n6A iWteX8MPZfbFs2VLvqs1mkssGIsqZjhsVD+NBWIXcoiy8Oz47Pkz9otRtE1rCDqJ7l63 Npos1vA8TsPiXqm/hwPRmGtIFdrjmGGdDVmApZiE246uf9PPjcRqJO10NP2kTC9JWd6p A/1JHU/QvSzr3KEH+vxDhHWaC9mNr1e7FJyQT+yjI+95AkpdSWMLannuRe6GHzWfDiGG LORK5MbsipqqucdUYq+lwf09oQlKcF54cybVvt6djIdGrpExJoWSaPGJGj1FnAMafTHA UL0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PmdNmV1W; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh14-20020a1709076e8e00b0072b45e10bb0si9163299ejc.922.2022.08.15.19.24.19; Mon, 15 Aug 2022 19:24:45 -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=@redhat.com header.s=mimecast20190719 header.b=PmdNmV1W; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244952AbiHPB0r (ORCPT + 99 others); Mon, 15 Aug 2022 21:26:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244731AbiHPB03 (ORCPT ); Mon, 15 Aug 2022 21:26:29 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 002621CDE60 for ; Mon, 15 Aug 2022 14:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660598161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SjOJ2ej9e5ff+yIWDnHyj8tdGUgmaChLo0SiD6yuEcY=; b=PmdNmV1WU2chuatIzKMvCAc0b7SnSmH+CNv9pFdoVgeV4uIVdUH2Ynu8By5Hayas6vJCHm 2fV+OFOkTz/Y3FRwWLZbYaIyMC4Uz5OUSPYdiArjzNfjl3I3/UzSjd9UGwZyJlK97K+vHv jkn3Q2ULrYukiXLaP+Q5zg6jJaP8DyQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-187-v-_WRz6XP0eM7eFaWMY6qg-1; Mon, 15 Aug 2022 17:15:56 -0400 X-MC-Unique: v-_WRz6XP0eM7eFaWMY6qg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0180C101A54E; Mon, 15 Aug 2022 21:15:56 +0000 (UTC) Received: from x2.localnet (unknown [10.22.34.141]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 61F4E492C3B; Mon, 15 Aug 2022 21:15:55 +0000 (UTC) From: Steve Grubb To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , linux-fsdevel@vger.kernel.org, Paul Moore , Eric Paris , Jan Kara , Amir Goldstein Subject: Re: [PATCH v4 4/4] fanotify,audit: deliver fan_info as a hex-encoded string Date: Mon, 15 Aug 2022 17:15:54 -0400 Message-ID: <4748539.GXAFRqVoOG@x2> Organization: Red Hat In-Reply-To: References: <5623945.DvuYhMxLoT@x2> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Hello Richard, On Wednesday, August 10, 2022 10:23:49 PM EDT Richard Guy Briggs wrote: > > I compiled a new kernel and run old user space on this. The above event > > is > > exactly what I see in my audit logs. Why the fan_info=3F? I really would > > have expected 0. What if the actual rule number was 63? I think this > > will work better to leave everything 0 with old user space. > > Well, if it is to be consistently hex encoded, that corresponds to "?" I suppose this OK. > if it is to be interpreted as a string. Since the fan_type is 0, > fan_info would be invalid, so a value of 0 would be entirely reasonable, > hex encoded to fan_info=00. It could also be hex encoded to the string > "(none)". If you wanted "0" for fan_type=FAN_RESPONSE_INFO_AUDIT_RULE, > that would be fan_info=30 if it were interpreted as a string, or > arguably 3F for an integer of rule (decimal) 63. Ultimately, fan_type > should determine how fan_info's hex encoded value should be interpreted. > > But ultimately, the point of this patch is to hex encode the fan_info > field value. Just one last update, I have been able to test the patches with the user space application and it appears to be working from the PoV of what is sent is what's in the audit logs. I'm not sure how picky old kernels are wrt the size of what's sent. But an unpatched 5.19 kernel seems to accept the larger size response and do the right thing. -Steve