Classic confinement request for hw-probe

Let’s go with classic confinement for now.

strict confinement cannot be used due to 3 remaining issues:

  • SMART attributes for hard drives cannot be collected for now. It’s very important for my current study:

  • Perl base modules from /usr/lib/x86_64-linux-gnu/perl-base/auto/ are currently denied to load. This blocks execution of the program.

  • The tool is intended to collect hardware operability details and system logs from the outside system. If it runs in the strict mode then it always detects Ubuntu Core instead (from /etc/os-release). I need a way to get content of outer /etc/os-release somehow.

Thank you.

1 Like

note that these perl modules might not exist in future core snaps, while (as @jamesh pointed out) currently a bug prevents you from using it, your snap should always ship all necessary bits in the snap anyway… there is no gurantee that perl-base will be in any future core snaps.

the system-observe interface provides access to /var/lib/snapd/hostfs/etc/os-release which is the host system os-release …

Regarding the SMART access, we probably need a new interface to provide this … this is up to @jdstrand to decide though …

1 Like

I’ve included perl-base to the snap and now it works almost fine. So let’s make it strict with the hope to improve probes by smartctl and hdparm outputs someday:

Can I request to auto-connect all required interfaces?

  • hardware-observe
  • mount-observe
  • network-observe
  • physical-memory-observe
  • system-observe
  • upower-observe
  • log-observe
  • kernel-module-control
  • raw-usb
  • home

Thanks a lot!

1 Like

Most of the *-observe seem reasonable for this snap. Can you comment on the following:

  • why is physical-memory-observe required? This is quite an information leak
  • why is log-observe required?
  • why is kernel-module-control required? This granted device ownership to the snap?
  • why is raw-usb required?
  • why is home required?

Please give very specific details on the required accesses (eg, down to executed commands with arguments). I suspect there might be some improvements to existing interfaces…

why is physical-memory-observe required? This is quite an information leak

It’s not used anymore… Removing from the snap.

why is log-observe required?

The tool collects Xorg.0.log to check if graphics card works properly. It’s depersonalized before collecting. See and

why is kernel-module-control required? This granted device ownership to the snap?

I’ve tried this interface to get output of lsmod command. It’s used to check if kernel modules are successfully loaded for particular hardware devices (e.g. if nvidia module is loaded and used by other modules). I don’t need to load any modules.

why is raw-usb required?

This is needed to get output of lsusb -v command to avoid the following error:

Couldn't open device, some information will be missing

why is home required?

The tool saves system analysis report to the HOME directory. User can refer to the report in future in the case of a system failure. I’m thinking about replacing it to SNAP_USER_COMMON and removing this dangerous interface from the snap. Is SNAP_USER_COMMON cleared after removing the snap?

Also the log Xorg.0.log can be found in the $HOME/.local/share/xorg/ directory in several Ubuntu versions, but it’s a rare case.

Thank you.

physical-memory-observe is required to get output of biosdecode. Adding it back to snap.

home is not needed anymore. Using SNAP_USER_COMMON instead.

Final list of required interfaces:

Waiting for How to launch sudo snap in Ubuntu Software? to be solved to allow my snap to be launched from the graphical installer (Ubuntu Software).

Thank you.

hardware-observe is meant to have some support for lsusb. What specific denials do you see when hardware-observe is connected but raw-usb is not?

hardware-observe + raw-usb vs hardware-observe lsusb diff:

  1. No power consumption details

  2. No Manufacturer names

  3. Diff:

     --- lsusb.orig	2018-09-25 08:25:28.491309180 +0300
     +++	2018-09-25 08:25:50.946069454 +0300
     @@ -1,3 +1,6 @@
     +Couldn't open device, some information will be missing
     +Couldn't open device, some information will be missing
      Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
      Device Descriptor:
        bLength                18
     @@ -10,8 +13,8 @@
        idVendor           0x80ee VirtualBox
        idProduct          0x0021 USB Tablet
        bcdDevice            1.00
     -  iManufacturer           1 VirtualBox
     -  iProduct                3 USB Tablet
     +  iManufacturer           1 
     +  iProduct                3 
        iSerial                 0 
        bNumConfigurations      1
        Configuration Descriptor:
     @@ -54,8 +57,6 @@
                Usage Type               Data
              wMaxPacketSize     0x0008  1x 8 bytes
              bInterval              10
     -Device Status:     0x0000
     -  (Bus Powered)
      Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
      Device Descriptor:
     @@ -69,9 +70,9 @@
        idVendor           0x1d6b Linux Foundation
        idProduct          0x0001 1.1 root hub
        bcdDevice            4.15
     -  iManufacturer           3 Linux 4.15.0-34-generic ohci_hcd
     -  iProduct                2 OHCI PCI host controller
     -  iSerial                 1 --
     +  iManufacturer           3 
     +  iProduct                2 
     +  iSerial                 1 
        bNumConfigurations      1
        Configuration Descriptor:
          bLength                 9
     @@ -103,30 +104,4 @@
                Synch Type               None
                Usage Type               Data
              wMaxPacketSize     0x0002  1x 2 bytes
     -        bInterval             255
     -Hub Descriptor:
     -  bLength              11
     -  bDescriptorType      41
     -  nNbrPorts            12
     -  wHubCharacteristic 0x0002
     -    No power switching (usb 1.0)
     -    Ganged overcurrent protection
     -  bPwrOn2PwrGood        0 * 2 milli seconds
     -  bHubContrCurrent      0 milli Ampere
     -  DeviceRemovable    0x00 0x00
     -  PortPwrCtrlMask    0xff 0xff
     - Hub Port Status:
     -   Port 1: 0000.0103 power enable connect
     -   Port 2: 0000.0100 power
     -   Port 3: 0000.0100 power
     -   Port 4: 0000.0100 power
     -   Port 5: 0000.0100 power
     -   Port 6: 0000.0100 power
     -   Port 7: 0000.0100 power
     -   Port 8: 0000.0100 power
     -   Port 9: 0000.0100 power
     -   Port 10: 0000.0100 power
     -   Port 11: 0000.0100 power
     -   Port 12: 0000.0100 power
     -Device Status:     0x0001
     -  Self Powered
     \ No newline at end of file
     +        bInterval             255
     \ No newline at end of file

can you also show us the denials you get with without raw-usb?

Could you please explain the question. What’s the difference with the question Classic confinement request for hw-probe?

Thank you.

Apparmor logs messages with details about what data it used to make a decision regarding whether to allow or deny an action. @chipaca is asking you to run your application both with, and without, the raw-usb plug and paste the log messages from Apparmor showing the denial decisions.

1 Like

No denials printed by or dmesg. Just silently reduces output of lsusb -v if raw-usb is not connected.

Thank you.

raw-usb grants more than just ‘observe’ to the snap and IMO, the lack of information when raw-usb is not connected is ‘ok’. If the user wants full information, then the user can manually connect it. -1 to auto-connect raw-usb.

+1 to:

  • hardware-observe
  • mount-observe
  • network-observe
  • system-observe
  • upower-observe
  • log-observe

-1 to physical-memory-observe. This is pretty powerful and the user can manually connect for biosdecode.

1 Like

@alexmurray, @natalia, @sergiusens and @Wimpress - can one/all of you vote on this?

1 Like

Not directly related to the request for interfaces - but can you instead use the udisks2 interface to get the SMART data? This then might require less specific access for hw-probe itself.

1 Like

@linuxhw - can you answer @alexmurray’s question?

@alexmurray, @natalia, @sergiusens and @Wimpress - can one/all of you vote on this?

1 Like

@alexmurray @jdstrand

Currently I’m learning how to query SMART attributes via DBus [1, 2] or udisksctl. But this is a temp solution. I’m looking forward to get report of smartctl -x /dev/sdX in future since it’s used in the HDD/SSD Real-Life Reliability Test study and by the smartmontools project team to improve drivesdb.h.

Thank you.

1 Like

Now that Alex’s question was answered, @alexmurray, @natalia, @sergiusens and @Wimpress - can one/all of you vote on this?

@jdstrand - I concur with your votes above (-1 raw-usb and physical-memory-observe, +1 hardware-observe mount-observe network-observe system-observe upower-observe log-observe)

2 vote for and 0 votes against:

  • hardware-observe
  • mount-observe
  • network-observe
  • system-observe
  • upower-observe
  • log-observe

Granting use of these interfaces. This is now live.

0 votes for and 2 votes against physical-memory-observe and raw-usb.

1 Like