From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D8638C00140 for ; Mon, 15 Aug 2022 21:16:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660598163; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=zH7VvifcTR9RnlmIIBeM/UimDr4hn9X0VSAEAx2WKns=; b=gjn+jd8bCmXBJyD7wbpyW2jDMT9HhlfxwJgNHAc1n1gmGl63g0Yoj6/doDRL2sL1hu//Za VoxhacsAS2bVgu1z6Ff2EWW3kh01wLrq/wKMGy55UsRwgXBQVDgaIK4jxf7kCW1EpLPoNk XXQRRb9hO8xeP6PmbNn9HpinHgH8obU= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-304-Guok9yzaNKClEKFHH4gAPQ-1; Mon, 15 Aug 2022 17:16:00 -0400 X-MC-Unique: Guok9yzaNKClEKFHH4gAPQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 43F053C11727; Mon, 15 Aug 2022 21:15:59 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 88A7740CFD0A; Mon, 15 Aug 2022 21:15:57 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 4E614194034E; Mon, 15 Aug 2022 21:15:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5E8F5194B966 for ; Mon, 15 Aug 2022 21:15:56 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 01090403166; 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 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 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jan Kara , Amir Goldstein , LKML , Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, Eric Paris Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit