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: https://github.com/linuxhw/SMART
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.
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 …
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: https://snapcraft.io/hw-probe
Can I request to auto-connect all required interfaces?
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 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.
hardware-observe + raw-usb vs hardware-observe lsusb diff:
No power consumption details
No Manufacturer names
Diff:
--- lsusb.orig 2018-09-25 08:25:28.491309180 +0300
+++ lsusb.new 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
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.
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.
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.
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.
@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)
