drivers/firmware/dmi-id.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
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 <noodles@meta.com>
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
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
On Mo, 12.06.23 09:59, Jonathan McDowell (noodles@meta.com) 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
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
© 2016 - 2026 Red Hat, Inc.