The /sys/devices/virtual/dmi/id/*_serial + product_uuid files are
currently only readable by root. There's no clear rationale for this;
Windows + OS X both allow regular users to access the information, so
there appears to be no expectation on the manufacturer side that it
should be kept secret.
Having the information easily available helps with automated tools that
collect system information for the purposes of fault diagnosis/tracking
without requiring the tools have root access.
(I've tried to look for context on the initial patch submission about
why these were root-only but didn't find any; hopefully Lennart or Kay
can provide details if I'm missing something.)
Signed-off-by: Jonathan McDowell <[email protected]>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103601
---
drivers/firmware/dmi-id.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/dmi-id.c b/drivers/firmware/dmi-id.c
index 5f3a3e913d28..ae700c09d7de 100644
--- a/drivers/firmware/dmi-id.c
+++ b/drivers/firmware/dmi-id.c
@@ -46,19 +46,19 @@ DEFINE_DMI_ATTR_WITH_SHOW(bios_release, 0444, DMI_BIOS_RELEASE);
DEFINE_DMI_ATTR_WITH_SHOW(ec_firmware_release, 0444, DMI_EC_FIRMWARE_RELEASE);
DEFINE_DMI_ATTR_WITH_SHOW(product_name, 0444, DMI_PRODUCT_NAME);
DEFINE_DMI_ATTR_WITH_SHOW(product_version, 0444, DMI_PRODUCT_VERSION);
-DEFINE_DMI_ATTR_WITH_SHOW(product_serial, 0400, DMI_PRODUCT_SERIAL);
-DEFINE_DMI_ATTR_WITH_SHOW(product_uuid, 0400, DMI_PRODUCT_UUID);
+DEFINE_DMI_ATTR_WITH_SHOW(product_serial, 0444, DMI_PRODUCT_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(product_uuid, 0444, DMI_PRODUCT_UUID);
DEFINE_DMI_ATTR_WITH_SHOW(product_sku, 0444, DMI_PRODUCT_SKU);
DEFINE_DMI_ATTR_WITH_SHOW(product_family, 0444, DMI_PRODUCT_FAMILY);
DEFINE_DMI_ATTR_WITH_SHOW(board_vendor, 0444, DMI_BOARD_VENDOR);
DEFINE_DMI_ATTR_WITH_SHOW(board_name, 0444, DMI_BOARD_NAME);
DEFINE_DMI_ATTR_WITH_SHOW(board_version, 0444, DMI_BOARD_VERSION);
-DEFINE_DMI_ATTR_WITH_SHOW(board_serial, 0400, DMI_BOARD_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(board_serial, 0444, DMI_BOARD_SERIAL);
DEFINE_DMI_ATTR_WITH_SHOW(board_asset_tag, 0444, DMI_BOARD_ASSET_TAG);
DEFINE_DMI_ATTR_WITH_SHOW(chassis_vendor, 0444, DMI_CHASSIS_VENDOR);
DEFINE_DMI_ATTR_WITH_SHOW(chassis_type, 0444, DMI_CHASSIS_TYPE);
DEFINE_DMI_ATTR_WITH_SHOW(chassis_version, 0444, DMI_CHASSIS_VERSION);
-DEFINE_DMI_ATTR_WITH_SHOW(chassis_serial, 0400, DMI_CHASSIS_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_serial, 0444, DMI_CHASSIS_SERIAL);
DEFINE_DMI_ATTR_WITH_SHOW(chassis_asset_tag, 0444, DMI_CHASSIS_ASSET_TAG);
static void ascii_filter(char *d, const char *s)
--
2.40.1
On Mon, Jun 12, 2023 at 09:59:50AM +0000, Jonathan McDowell wrote:
> The /sys/devices/virtual/dmi/id/*_serial + product_uuid files are
> currently only readable by root. There's no clear rationale for this;
> Windows + OS X both allow regular users to access the information, so
> there appears to be no expectation on the manufacturer side that it
> should be kept secret.
>
> Having the information easily available helps with automated tools that
> collect system information for the purposes of fault diagnosis/tracking
> without requiring the tools have root access.
>
> (I've tried to look for context on the initial patch submission about
> why these were root-only but didn't find any; hopefully Lennart or Kay
> can provide details if I'm missing something.)
I think it was just generic "let's not expose anything that might be a
secret", but if Windows exposes all of this to any user, then vendors
are used to it, so it's not a big deal.
thanks,
greg k-h
On Mo, 12.06.23 09:59, Jonathan McDowell ([email protected]) wrote:
> The /sys/devices/virtual/dmi/id/*_serial + product_uuid files are
> currently only readable by root. There's no clear rationale for this;
> Windows + OS X both allow regular users to access the information, so
> there appears to be no expectation on the manufacturer side that it
> should be kept secret.
>
> Having the information easily available helps with automated tools that
> collect system information for the purposes of fault diagnosis/tracking
> without requiring the tools have root access.
>
> (I've tried to look for context on the initial patch submission about
> why these were root-only but didn't find any; hopefully Lennart or Kay
> can provide details if I'm missing something.)
When I originally added this in 2007 the intel cpuid serial numbers
kerfuffle wasn't ancient history yet, i.e. see:
https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_privacy_issues
So we wanted to ensure that potentially identifying hw information
would not leak to unprivileged code just like that so easily, hence
restricting this was the easy way out.
We subsequently came up with the /etc/machine-id concept, i.e. a
*user* controlled ID value people can use instead. And for VMs we then
added logic so that the VM supplied UUID can be propagated into that
(under the assumption that the VM supplied UUID is under user control
anyway).
To my knowledge on ChromeOS the /etc/machine-id concept isn't much
liked either, they'd rather have *no* identifiable info available to
unpriv code instead of just user controllable ids... (i remember some
conversations with chromeos people back in the day about this.) if you
open up the DMI serial numbers like this you might not make yourself
many friends in that camp...
One might argue that there's always some identifiable hw info available
for apps to use, or that apps should run in sandboxes that make this
impossible, but that's cheap of course…
Lennart
--
Lennart Poettering, Berlin
Hi Jonathan,
On Mon, 2023-06-12 at 09:59 +0000, Jonathan McDowell wrote:
> The /sys/devices/virtual/dmi/id/*_serial + product_uuid files are
> currently only readable by root. There's no clear rationale for this;
> Windows + OS X both allow regular users to access the information, so
> there appears to be no expectation on the manufacturer side that it
> should be kept secret.
> (...)
I'll think about it. However, please note that these permissions are
only initial permissions, and nothing prevents user-space from changing
them at run-time. So if a Linux distribution believes there's no reason
to keep these values secret, a simple boot-time script (or maybe just a
couple of udev rules, I'm not sure how powerful these are nowadays)
would solve the problem.
--
Jean Delvare
SUSE L3 Support