Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5463750pxb; Wed, 26 Jan 2022 12:35:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJy4TjKZ+fLLWwLEdyhesb7jTKr1x4EdeGj5OUX2N+winLow1hF54wUi41ono/5GFCF6WvtX X-Received: by 2002:a17:903:22d0:: with SMTP id y16mr673692plg.35.1643229339873; Wed, 26 Jan 2022 12:35:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643229339; cv=none; d=google.com; s=arc-20160816; b=EI/SREepo2X0452AYyJnKVKQw/5oUNt3gi959KANiL5H3fQpdlqyHhv0atNvOFPpd5 eyWijPYmAXnquSERupUdc/qRJOesZtxh3BEf4C0/3G5XTe3pcQFjsJn6k41qHYQgQLLl jjWY8meSwV/RNJJpEFUcMr2SbTMEYkFe4Q9bvyDK1GqkZ5FcvWeOWnNT7Zvyu/oo6iPt FH5ZNbtE8kDmYtc/VrDqSdpKFPpe1uSACzemKmMOomLLHXPBrJ1vtJM8gSgXx+UDit8n CK+b9GUZqzdhEwAAM+gdeZQ5MHDTPFKUkxA9QdUfF/B2+M3Ove01Oj6+P+UC/F4ywBrN 3lJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=c4Kg+TFpD9rFGeE4TVcwxqtM6/36lWfNfYO5K7rAmG0=; b=eaFIs0i1dL624za7wTb1pmG40nB6sN+dNLPWCuEjSs3qOoRD3AGtAFkqX7aGqlH4Ix MvM35VwVBPjyRLwSOTveN7mYN0NGAvzFoKV7Jwxu0dU8BwfFlsQ+VzyNX72pP50zB0EZ xhiDK/lBVSutU6Psq//x+41ykhBx1KRobe6y5em9luhdO4g2/ThZlXYJnGtNRyMDvcFF XjBdArYN0ffLwODY5x0GzvxmRKdUnxTQiXN1xatXL2Gv8l81j8pgFwdvhAYRuTp+MGj3 x1yxNQHNIDv6E6HETDtkdtO5GW1pf8ZjxGLblNj5s1oo5ht/ciAuFgsySk+si6VYGu3L oJcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pNb+YTM6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g189si262447pgc.171.2022.01.26.12.35.25; Wed, 26 Jan 2022 12:35:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=pNb+YTM6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238527AbiAZIi0 (ORCPT + 99 others); Wed, 26 Jan 2022 03:38:26 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:42308 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230519AbiAZIiZ (ORCPT ); Wed, 26 Jan 2022 03:38:25 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B4A7CB81C0D; Wed, 26 Jan 2022 08:38:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C61EC340E3; Wed, 26 Jan 2022 08:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643186302; bh=hql5taXDX4ZFmojFgMRXFkOGKx291CxE+GSNeSfAA2c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pNb+YTM6/mJuqAYTriG5zewRhHzjPggPybHpoW8TTb59Zd19gxWB+rotrC6gceiZI aNYPvP5pSSYQKToxenZI6nFnIV7BbVqeXKHRsXl7cgtqYGdsk5Ww6saclUG/juZHhU DRwmm4doPU4RrdV1ehlVGIrxpIkOuWVP7huqJsmNMl3eWUgsTBTLkR5Yrq4hUd427k ljHiNHVKcLEGP8sirEGX0NJWHdtNZSW4Jy1GRWON4i9isvXo7vH0Ks+l4EEqwOFil4 pqiXmnpmZTP3AdsYYeSaU+mUeO+RysNjQR9OGFglrTSz6GT1PKmkYdn1Js7gEkKTFy x+lyBwK1EV8uw== Date: Wed, 26 Jan 2022 09:38:14 +0100 From: Christian Brauner To: Stefan Berger Cc: linux-integrity@vger.kernel.org, zohar@linux.ibm.com, serge@hallyn.com, christian.brauner@ubuntu.com, containers@lists.linux.dev, dmitry.kasatkin@gmail.com, ebiederm@xmission.com, krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com, mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com, puiterwi@redhat.com, jejb@linux.ibm.com, jamjoom@us.ibm.com, linux-kernel@vger.kernel.org, paul@paul-moore.com, rgb@redhat.com, linux-security-module@vger.kernel.org, jmorris@namei.org, Stefan Berger Subject: Re: [PATCH v9 02/23] ima: Do not print policy rule with inactive LSM labels Message-ID: <20220126083814.3ndwkhivir573aok@wittgenstein> References: <20220125224645.79319-1-stefanb@linux.vnet.ibm.com> <20220125224645.79319-3-stefanb@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220125224645.79319-3-stefanb@linux.vnet.ibm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 05:46:24PM -0500, Stefan Berger wrote: > From: Stefan Berger > > Before printing a policy rule scan for inactive LSM labels in the policy > rule. Inactive LSM labels are identified by args_p != NULL and > rule == NULL. > > Fixes: b16942455193 ("ima: use the lsm policy update notifier") That commit message of the referenced patch reads: "Don't do lazy policy updates while running the rule matching, run the updates as they happen." and given that we had a lengthy discussion how to update the rules I'd really would have liked an explanation why the update needs to run immediately. Not doing it lazily is the whole reason we have this notifier infra. Why can't this be done lazily?