Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1135537pxv; Fri, 23 Jul 2021 00:07:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxi7D/1WgJOg9LVD4YNNBGiU1bEb7tS8b2ShPdOA4Wtx8ghNZmLtwdypeWNby8WRQ4lxE1o X-Received: by 2002:a05:6402:c96:: with SMTP id cm22mr3822213edb.132.1627024043998; Fri, 23 Jul 2021 00:07:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627024043; cv=none; d=google.com; s=arc-20160816; b=WIFShYRBwiygeFogDTq18YEPhy3EO+Cna6z5J+UYQEjjC3qsaCFg43mrwzf8s/2Hfy UwMP25QDuE9fDoUx5U3+1rELx2ua6bZeAIcVNmzpkw+JWuS3MZg4Gkh3lKcsjGRx71hM zT92BKwyJrNQ2TYvSFbxgmjXyFkYs5RIcnRj4VNWfRGZNWecuLgZ2B9ugYD3b2xaZq7D nFbeDUlq6+E3DT2mil+6qxLZJzI4VarrlX+K6DmAXp07CExBblZArSpYNzEkVekuXyLb D/8/xroSpOQuyYvmVCsp+oDD4kfUGkH5l5IpX3KBgqjCmnf0L7SoZ4Eg7Rd+7oEDY8Rv 2oOA== 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=Iud9vhI6SfO4A3eIax8Bgn+TI7oiIiAVVHjRn5SHHrs=; b=suAW9Eu9VvapityoiAskneRFEm8bSo5DC7XD7qD1qtAfTa+fcN49QSfaNM2PSt/nom GqOKK/SZDavyYnVe1HE4jtlm/oB6ykKZqXWMnqd3szd4WiSgIEtEyNqCzbGFUD4KvXy3 4syilUj7dweH3CVjQlArpqQwAP/Gl9WHe3PNYjbI+BiPxTjHGIygKwz9j+CD7IigWluN lDJIUkjXkNrgqyf1NIrOGKetCqIO5iZ4byPcFmyfOLLMdFC2JhxjbbHUP13zuQit9cTP MiekQWC5WEYYr6z8xos6mljZGuJ1oDkyqWf9znyHh4z4dC386UBsJgxqmmN5NjJLP+sJ euUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KU+G+f3V; 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=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y15si3637052ejc.52.2021.07.23.00.07.00; Fri, 23 Jul 2021 00:07:23 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KU+G+f3V; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234227AbhGWGYn (ORCPT + 99 others); Fri, 23 Jul 2021 02:24:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:59394 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234089AbhGWGYl (ORCPT ); Fri, 23 Jul 2021 02:24:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7D09260EAF; Fri, 23 Jul 2021 07:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627023914; bh=bdg4IKmEOmIJGi9bkVNvHhOylDYZgIWiL34s3A6QfpU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KU+G+f3V+IKPMrH7fYe6wtoHAY292z9gPpkLy1mRmfD+9fI6nY2gSqQX1dBQPeoRK oXNUBVPiVjRS4pokelk4eS6v9UEuJ/j7F2ZibDKupbXHZsAQmBFXL3QncaDzvC0IoP se6vu0db4vug1+ZCIzEXP/EgSDZs0WJS6f6i4P/8= Date: Fri, 23 Jul 2021 09:05:11 +0200 From: Greg KH To: Rajat Jain Cc: Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, rajatxjain@gmail.com Subject: Re: [PATCH] thunderbolt: For dev authorization changes, include the actual event in udev change notification Message-ID: References: <20210723012835.1935471-1-rajatja@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210723012835.1935471-1-rajatja@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 22, 2021 at 06:28:34PM -0700, Rajat Jain wrote: > For security, we would like to monitor and track when the > thunderbolt devices are authorized and deauthorized. Currently > the userspace gets a udev change notification when there is a > change, but the state may have changed (again) by the time we > look at the authorized attribute in sysfs. So an authorization > event may go unnoticed. Thus make it easier by informing the > actual change (authorized/deauthorized) in the udev change > notification. We do have 72 columns to work with... :) > > Signed-off-by: Rajat Jain > --- > drivers/thunderbolt/switch.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c > index 83b1ef3d5d03..5d3e9dcba44a 100644 > --- a/drivers/thunderbolt/switch.c > +++ b/drivers/thunderbolt/switch.c > @@ -1499,6 +1499,7 @@ static ssize_t authorized_show(struct device *dev, > static int disapprove_switch(struct device *dev, void *not_used) > { > struct tb_switch *sw; > + char *envp[] = { "AUTHORIZED=0", NULL }; > > sw = tb_to_switch(dev); > if (sw && sw->authorized) { > @@ -1514,7 +1515,7 @@ static int disapprove_switch(struct device *dev, void *not_used) > return ret; > > sw->authorized = 0; > - kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE); > + kobject_uevent_env(&sw->dev.kobj, KOBJ_CHANGE, envp); > } > > return 0; > @@ -1523,6 +1524,8 @@ static int disapprove_switch(struct device *dev, void *not_used) > static int tb_switch_set_authorized(struct tb_switch *sw, unsigned int val) > { > int ret = -EINVAL; > + char envp_string[13]; > + char *envp[] = { envp_string, NULL }; > > if (!mutex_trylock(&sw->tb->lock)) > return restart_syscall(); > @@ -1560,7 +1563,8 @@ static int tb_switch_set_authorized(struct tb_switch *sw, unsigned int val) > if (!ret) { > sw->authorized = val; > /* Notify status change to the userspace */ > - kobject_uevent(&sw->dev.kobj, KOBJ_CHANGE); > + sprintf(envp_string, "AUTHORIZED=%u", val); > + kobject_uevent_env(&sw->dev.kobj, KOBJ_CHANGE, envp); So now "val" is a userspace visable value? Is that documented anywhere what it is and what are you going to do to ensure it never changes in the future? Also this new value "field" should be documented somewhere as well, otherwise how will any tool know it is there? And what userspace tool will be looking for this? thanks, greg k-h