Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1712114pxa; Thu, 20 Aug 2020 19:32:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy9WAa4LLOaQWglXEGaEkLQpBRHu36iGC3CTK7Chv6Yzr0MBwgUChvPXQwkaFOJYp9vNa+j X-Received: by 2002:a05:6402:486:: with SMTP id k6mr776208edv.83.1597977175472; Thu, 20 Aug 2020 19:32:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597977175; cv=none; d=google.com; s=arc-20160816; b=NLmgLoiyJKfkQLje5BEeXWuA9qwmFzJ8lJY+DoZAI7OgKoTwTzFonTKUstyxhU1ZYW CyGNlrP/JzCgRINBVIVY5wk92TvTwPWUBFWfx9a+5ypD2c1rdZlmDuaO6/A8X/DHnt5X w2u/yHrEdelWmi8IFFrZTkMerTWBVsE1EEWznopUcRdQJapIsrouFvmV0V0SYS0qWmE7 a0m8FvG9EdkwGf1NHffiSdztgb3bE8CkP0Htp5zIinTIsr3UZ58zmUCZToLnnxEDz7SW xGm9EwaOzVq4KGSZaCquwm+nsu7Zb3vnRWxWU2LbW8e7cP5AGZHSQC+1jPxp6euiUANN 24Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=mYkSx+8TEX6mzNrQV04SQyYRKU5ZK4ML5Ll7ReGa9jc=; b=0C5m5W4V9WTFRWNHNhfkd6WykqzAo7nTaxO4/z4vGfk7j1Nn6xKDmWtFCF41zKYA2Y w6ScGOkUV8Fq06aV/2k+58njN1P23asOa/XTZYP65xFtAYg83yvGOw9PhMiOj/MyOLoy F4HY/+w91jpYMWuFlxxxOTEz+oOQx5wYCialkfTxWg7z4Y9nzRDwWr5VPun4ufE0MBMG 2ABGymUdc+VZdEoPGMmn+jsSSFG8107bXnr2fnaozLXvvZCwPBA0bQ5Y+UY84qGyP6KV YH8L7QKMHlEQM+o+QoTv5KBTxZlwILSgrImFwPmMFlETBo8Kqw2dhGNZkj0kRssEycNp caUQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rs22si244124ejb.751.2020.08.20.19.32.31; Thu, 20 Aug 2020 19:32:55 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727053AbgHUCbk convert rfc822-to-8bit (ORCPT + 99 others); Thu, 20 Aug 2020 22:31:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:60210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726885AbgHUCbj (ORCPT ); Thu, 20 Aug 2020 22:31:39 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E4E4F20748; Fri, 21 Aug 2020 02:31:37 +0000 (UTC) Date: Thu, 20 Aug 2020 22:31:36 -0400 From: Steven Rostedt To: Stephen Smalley Cc: =?UTF-8?B?VGhpw6liYXVk?= Weksteen , Paul Moore , Nick Kralevich , Peter Enderborg , Eric Paris , Ingo Molnar , Mauro Carvalho Chehab , "David S. Miller" , Rob Herring , linux-kernel@vger.kernel.org, selinux@vger.kernel.org Subject: Re: [PATCH v3 3/3] selinux: add permission names to trace event Message-ID: <20200820223136.162850ce@oasis.local.home> In-Reply-To: <66e6d84e-20b5-1bd3-e107-322f42ce35d3@gmail.com> References: <20200817170729.2605279-1-tweek@google.com> <20200817170729.2605279-4-tweek@google.com> <0bb62de9-1020-a7c4-3a7f-48ae2f78e3b7@gmail.com> <20200817162933.79f69c66@oasis.local.home> <20200818120948.1a428da9@oasis.local.home> <66e6d84e-20b5-1bd3-e107-322f42ce35d3@gmail.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 19 Aug 2020 09:11:08 -0400 Stephen Smalley wrote: > So we'll need to update this plugin whenever we modify > security/selinux/include/classmap.h to keep them in sync.  Is that a > concern?  I don't suppose the plugin could directly include classmap.h?  > I guess we'd have to export it as a public header. It isn't considered > to be part of the kernel API/ABI and can change anytime (but in practice > changes are not that frequent, and usually just additive in nature). Yes, it would require some stability between userspace and the plugin. If the value indexes don't change then that would work fine. If you add new ones, that too should be OK, just have a way to state "unknown" in the plugin. -- Steve