Manual review request for Visual LVM 5.2

store-requests
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

22

Publisher is now vetted. Could you please resubmit your snap with the interface naming adjustment @emitorino suggested. Thanks!

23

Hi @cav,

New snap(5.2.1177) submitted.

24

Hi @cav,

The snap with modified interfae name was submitted.

25

Hey @isaac.clack,

Thanks for he update. Since publisher vetting is completed and updates have been applied, I have granted auto-connect of dm-crypt and use (but not auto-connect) of system-files to visual-lvm-remote. This is now live.