Manual review request

store-requests
4

@weLees ping, can you please provide the requested information?

5

Hi emitorino, Sorry for the late reply, but we are currently solving an urgent issue of Visual LVM, we will try after completion

1 Like
6

Hi, the new version(4.4) submitted, we remove system-files interface. Please review thanks

7

I notice your snap is still using system-files:

plugs:
  etc-lvm-backup:
    interface: system-files
    read:
    - /run/lvm
    - /sys/firmware/dmi/tables
    - /sys/devices
    - /proc
    write:
    - /etc/visual_lvm
    - /dev/mapper
    - /run/lvm
    - /run
    - /dev
    - /sys/devices/virtual/bdi
  null-device:
    interface: system-files
    write:
    - /dev/null

So this has not been removed. Can you please clarify?

8

In the latest version 4.4.779 We try best to remove system-files referencing, only 3 left

interface: system-files
write:
  - /dev    ------for fdisk enumerate disk
read:
  - /sys/devices    --------to get disk information(vendor/type)
  - /proc           ---------to enumerate md(raid) device

Without them, we can’t show user the storage information

9

Hello @weLees, did you try to use the system-observe and hardware-observe as mentioned in the previous comments?

10

Yes, we have tried but fail…

11

@weLees apologize for this long discussion but we are trying to help you follow the best practices for snapping your application.

It is not correct to grant the wide access to /proc, /dev etc without really understanding why you are not able to make your snap work using the suggested interfaces. Can you please try to use them and share here the AppArmor denials you are seeing? This will be very helpful for us to get a better understanding and hopefully help you make your snap work the correct way.

If this helps, this is a recent application we have granted declarations Approval request for list-filesystem - lfs and is able to list drives utilization by plugging some of the interfaces we have suggested.

Thanks!

12

@weLees - hello, can you please provide the requested information? What denial messages are you seeing?

13

Hi, rev480 subbmitted, it uses followed plugs:

apps:
  start:
    plugs:
      [block-devices,network-bind,hardware-observe,network,system-observe]
    command: bin/vlvmservice start $SNAP_DATA
  stop:
    plugs:
      [system-observe]
    command: bin/vlvmservice stop $SNAP_DATA

  restart:
    plugs:
      [block-devices,network-bind,hardware-observe,network,system-observe]
    command: bin/vlvmservice restart $SNAP_DATA
14

Thanks for the update - so the only interface in this list which is quite privileged is block-devices - this essentially allows a snap to control the entire device - can you please explain why this is required for Visual LVM Remote? Also note that to be granted access to this interface, publisher vetting would be required as well.

15

Visual LVM need to read metadata information of LVM from PV(disk/partition). So we have to access the block-devices such as /dev/sdx /dev/hdx

16

Can you please try and be more specific on what exactly is required here? Are there particular files that are being accessed and if so can you please detail these?

I wonder if mount-observe might be sufficient for this purpose? Or perhaps you can use udisks2 to query this information via DBus? The more information you can provide on what exactly Visual LVM Remote requires then the more help we can give to come to a solution. Thanks.

17

Hi, thanks for your reply. To detect LVM components, we need to read the head(sector 1-4) of PV to get PV information, and read head and/or tail of device to get VG information(it depends settings). So we have to read head/middle/tail of disk for disk & partition can be PV.

18

Hello! So Visual LVM had been refused?

19

Hey @weLees, apologize for the delay. Visual LVM has not been refused!

Thanks a lot for updating visual-lvm-remote and applying all the suggestions provided. I am then +1 for auto-connect hardware-observe and system-observe to visual-lvm-remote. I am +1 for use but not auto-connect of block-devices due to the sensitiveness of the accesses when granted.

Can other @reviewers please vote?

20

+1 from me too for use-of and auto-connect of hardware-observe and system-observe to visual-lvm-remote. Similarly, +1 only for use-of but not auto-connect of block-devices as this grants device ownership to the snap. However, regardless, we still require publisher vetting in this case as well. @advocacy can you please perform publisher vetting?

21

@emitorino @alexmurray Thanks for your work. We are waiting for good news :slight_smile:

1 Like
22

+1 from me, I vetted the publisher.

23

+2 votes for, 0 votes against. Granting auto-connect of hardware-observe and system-observe to visual-lvm-remote. Granting use but not auto-connect of block-devices to visual-lvm-remote. This is now live.