Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp146051ybl; Tue, 3 Dec 2019 23:44:56 -0800 (PST) X-Google-Smtp-Source: APXvYqwmXm8+mFMRdAu+qAEZ7DsO7F7g4FUfdDP/z6iorw3NRiXExCVc+nprAMM3wx3dFgpXNN2l X-Received: by 2002:aca:39c2:: with SMTP id g185mr1452149oia.150.1575445496211; Tue, 03 Dec 2019 23:44:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575445496; cv=none; d=google.com; s=arc-20160816; b=pgxktmOH3iLjBWU3gcYgSBDnYj+CM57fbzSIW5Nri2MdwpuYkl/YUZKbwqr0sCNOb2 LDSvAp+9d4RxxFeRGRbnpAPz1Er/2tGOiOwxxulbhY23p7FpMdI+ft1IWiw4uDinQoUs O780n+PjG0EHkrNYnCk8HsFFAEN7O/EKDjcx/JcTnKeJQ5yc7Aby1c90GG58DdMkFPLG q7RfPyGCIQKScWsrSquzYQrzvhjkuJMOEDCV9T1cTkK2EXPJ4NCqXnRYl54vWC9/UxhI jSq4C4vR1oXbydjZ3E2oQ2bEPyWg4hn9kJqUbbZvxn27dLfFFa8wYZHJnUPnPnDPbqBE Ursw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=nuW/pbERMnFCon7oBJuH1iWb4nVszVnO7ci4+mmWeN4=; b=AElI+YMKZeT+NE1HReOZS9m9Zv4NHqfcpRPj80kkCsbV0HD9hRXOyGuk35ZzeENrYp JN/+gIbOZYa4WRdQLn8vkaQQHOwRIJXszITeGUdgNFsvUCrGKX4urmY84aXKqkY3K3k7 GZGkKEgHJVKDVtnt5g2wXrFnB7k9Zx+2Sz5AcHjA1Zb9vXQoEqi51PGfvnjj/ZAvVtxZ UsI9m8BajHM0wcNf1Da5oO3nvyDXiennl/IRIwBHdLH+FrI+EgToLA62FftaEQiemQhl Ctk6VJNrHIV/8qtSHT5dAvTfpFAhSNDDIOmExN+wVKGJh/OsqUHJhIeMrlbN+kUwFJgN 8Rig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vPVuNcSi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t195si708382oih.209.2019.12.03.23.44.27; Tue, 03 Dec 2019 23:44:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vPVuNcSi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726679AbfLDHlg (ORCPT + 99 others); Wed, 4 Dec 2019 02:41:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:43686 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726048AbfLDHlg (ORCPT ); Wed, 4 Dec 2019 02:41:36 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 064132054F; Wed, 4 Dec 2019 07:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575445295; bh=mXmse0izUm18/vYwWZA7L1FmvwrmsFcAgHgaFLg8fWM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vPVuNcSihDBFHN/wNcDvXq3nX0PneSL8zEKch9efO0LW0YXIFLkRq65kWAWxSUa6r p8e7vcAFueJXx/qpiT31yGnClZWi5Bv0OKijGX1xLFCqOU8nYNYlG3eWC7+TNzffly wRtG9NEGan8H8WOT2lSbnvfmPvioK70OMUP089yg= Date: Wed, 4 Dec 2019 08:41:33 +0100 From: Greg Kroah-Hartman To: Guoheyi Cc: Mike Waychison , linux-kernel@vger.kernel.org, wanghaibin 00208455 , Thomas Gleixner Subject: Re: firmware: dmi-sysfs: why is the access mode of dmi sysfs entries restricted to 0400? Message-ID: <20191204074133.GA3548765@kroah.com> References: <42bb2db8-66e0-3df4-75b7-98b2b2bcfca8@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42bb2db8-66e0-3df4-75b7-98b2b2bcfca8@huawei.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 04, 2019 at 03:31:22PM +0800, Guoheyi wrote: > Hi, > > Why is the access mode of dmi sysfs entries restricted to 0400? Is it for > security concern? If it is, which information do we consider as privacy? There's lots of "interesting" information in dmi entries that you probably do not want all processes reading, which is why they are restricted. > We would like to fetch CPU information from non-root application, is there > feasible way to do that? What specific CPU information is not currently exported in /proc/cpuinfo that only shows up in DMI entries that you are interested in? You can always have root change the permissions of a sysfs file if you have a service that wants to allow non-root programs to read specific entries. thanks, greg k-h