Manual review request for Visual LVM 5.2

store-requests
1

Hi, The Visual LVM 5.2 was released, please review it. Thank you

3

hi @isaac.clack , the new revision is using dm-crypt and system-files interfaces, can you help us understand the use case of these interfaces.

plugs:
  access:
    interface: system-files
    read:
    - /dev
    - /sbin
    write:
    - /run/lvm
    - /run/lock/lvm
...
...
apps:
  change-password:
    command: command-change-password.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe
  change-port:
    command: command-change-port.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe
  ip-accept:
    command: command-ip-accept.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe
  ip-refuse:
    command: command-ip-refuse.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe
  restart:
    command: command-restart.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe
  start:
    command: command-start.wrapper
    plugs:
    - dm-crypt
    - block-devices
    - network-bind
    - access
    - network
    - system-observe

Thanks

4

Hi @0xnishit

Happy new year.

The dm-crypt interface is used to connect a device mapper to perform LV operations.

The /dev is used to read the PV header.

The /sbin is used to read the file systems that can be created in the local system.

/run/lvm and /run/lock/lvm are used to perform PV and VG operations.

Thank you.

5

hey @isaac.clack ,

I found this post where similar things were achieved without using system-files interface with this wide access(which we don’t recommend) on dev and sbin dirs. Have you tried using mount-observe or any of the suggested interface from this post?

thanks

6

Hi @0xnishit, We found that the /snap/core/current/sbin directory seems to be a mirror of the local /sbin directory, and it is OK to look for matching files from this directory, but are there any environment variables pointing to this directory or its parent directory?

7

Hi @0xnishit, Could you answer my question? Thank you

8

I am not sure, can any other @reviewers provide suggestion here?

thanks

9

Hi @isaac.clack this is the doc for the available env variables available for the snap application: https://snapcraft.io/docs/environment-variables

10

Your snap runs inside a namespace on top of the defined base: snap so you dont really need any environment variables, /sbin is simply identical to /snap/<base>/current/sbin since your base snap becomes your root filesystem at rutime and /bin, /sbin, usr/bin and /usr/sbin are in your PATH …

you can test that by spawning a shell inside the snap environment with the snap run --shell <snapname>.<appname> command (exit it with ctrl+d or the exit command)

11

Hi @ogra, When I try to run ‘ls /sbin’ in snap shell, it shows “ls: cannot open directory ‘/sbin/’: Permission denied” So I cannot get mkfs.*…

12

well, what i meant so say is that /sbin and /snap/<base>/current/sbin are identical, there is likely an apparmor policy that blocks listing its contents, but that would be the exact same for /snap/<base>/current/sbin:

$ snap run --shell htop -c 'ls /sbin'
ls: cannot open directory '/sbin': Permission denied
$ snap run --shell htop -c 'ls /snap/core22/current/sbin'
ls: cannot open directory '/snap/core22/current/sbin': Permission denied
$
13

Hi @isaac.clack

Would it be an option to stage mkfs related packages (e.g. dosfstools, util-linux, e2fsprogs) and access the binaries via $SNAP/sbin?

1 Like
14

Hi @ogra,

I know that the /sbin/mkfs.xxx cannot be run in snap now, so ignore this case please.

And now the visual-lvm-remote 5.2.1172 was pushed(remove access of /dev & /sbin), please review it.

Thank you!

15

Hi @jslarraz, I got it now! your advise is right. Thank you

16

Hi @0xnishit,

I have removed access of /sbin & /dev in rev 5.2.1172. Please review it. Thank you!

17

I think dm-crypt is providing more accesses than the ones required by visual-lvm-remote but seems to be the more appropiate iface to grant access to /dev/mapper/control as needed.

@isaac.clack: Does visual-lvm-remote require this access for basic operations or it is needed for some specific use cases? I ask since I will then be +1 for use of dm-crypt but since its a super privileged interface, I would avoid auto-connect unless this is required for the snap to properly operate on general use cases.

Following a similar reasoning, since this snap is not the owner of /run/lvm, I vote +1 for use (and not auto-connect) of system-files. Also, I suggest you rename the iface reference access to run-lvm to better represent to the user the access being granted.

Can other @reviewers please vote? Thanks!

18

+1 from me as well for connect of dm-crypt and pending the system-files interface name change to run-lvm, +1 for a connect.

19

Hi @emitorino,

The dm-crypt is used for LV operations, it is a basic request.

20

Hi @emitorino, What’s the status now?

21

Given the snap seems to need auto-connect of dm-crypt as it is needed to operate generally, and because the snap needs to connect to /run/lvm which it does not own, I will perform publisher vetting