Request for classic confinement for Quicknav

store-requests
1

Hi there,

I would like to request classic confinement for my snap ‘quicknav’.

Quicknav is a command line tool for quickly jumping around different locations on your filesystem (https://github.com/MrDogeBro/quicknav). Quicknav needs classic confinement to be able to read and write to the config file as well as create directories in a path if they don’t exist.

Thanks!

2

Hi @MrDogeBro,

If you check our Process for reviewing classic confinement snaps, the access to arbitrary files on the system isn’t typically a justification for classic. Strictly confined snaps can access users’ files with the home and the removable-media interfaces (which is almost always sufficient). personal-files and system-files may be used as well if needed.

Could you please try them out? In case you are not familiar with it, I suggest using snappy-debug during troubleshooting. It will recommend interfaces based on the behavior it observes in your snap. Feel free to add here any further question you might have.

Thanks!

3

@emitorino Thanks for the reply. I did check that out and apparently read wrong. Does this mean that with the strict confinement I should still be able to just access config files at ~/.config/quicknav/ and create and edit files and folder in other places in the users home without altering my CLIs code? If so, I seem to have read wrong. If so, sorry for wasting your time. Thanks!

1 Like
4

Hey @MrDogeBro, that’s correct.

Also, snaps have $HOME set to ~/snap/< snapname >/current so you could simply use the $HOME environment variable in your snap (provided this is useful). The home interface allows access to all of the user’s actual home where the user owns the files, except for top level dot files/directories . The security-policy-and-sandboxing doc contains a detailed explanation about the environment variables available (as well as general confinement details)

Also, the system-backup provides read-only access to the system via /var/lib/snapd/hostfs.

Do you think you could keep your snap under strict confinement and make use of some of those interfaces instead? This way you can enjoy all the benefits of a stable runtime environment which classic snaps have.

As mentioned above, snappy-debug could help you understand the missing interfaces while troubleshooting.

5

@emitorino I am confused. According to the forum post on the home interface, it “allows access to non-hidden files owned by the user in the user’s home ($HOME) directory” which would mean I couldn’t access places like .config for the user correct. Because I need to be able to do that.

Also, my code currently looks at the $HOME variable for expansion of certain paths, meaning if this is ~/snap/quicknav as you stated above, that would mess that up most likely correct?

I also would not like to modify my code to try and work around some of these things because I already distribute on other package managers and do not want to be maintaining two different versions; one for normal and one for snap.

If I can easily get it to work on strict confinement, I would not mind doing that plus there are the benefits of that. But if there would have to be major changes to the code, I would prefer not to do those just to use strict.

Thanks!

6

@MrDogeBro so there is also the personal-files interface which you could use in that case. As stated there:

Snaps by default have access to everything under $SNAP_USER_DATA (eg, ~/snap/<snap name>/<revision>) and $HOME is set to $SNAP_USER_DATA for non-daemon commands. As a result, snaps may freely read and write to dot files in their $HOME (ie, ~/snap/<snap name>/<revision>/...)

The personal-files interface is typically used to provide read-only access to top-level hidden data directories within a user’s real home directory in order to support importing data from existing applications where the snap is the clear owner of the target directory.

So I encourage you to test your snap and make sure it works as you expected. You can install it locally and check. This post gives useful hits to do so. I suggest you work locally before pushing the snap to the store until you are sure about what your snap needs and why. You could start with devmode, and then switch to strict confinement once you get such understanding. Please see this video for further details. You could also inspect variables expansion if you run something like:

$ snap run --shell hello-world.env
$ echo $HOME
/home/<user>/snap/hello-world/29

Unfortunately there are only certain categories under which classic confinement can be granted (please check the link I shared in my original response: Process for reviewing classic confinement snaps). And this is because classic confinement snaps run without restrictions, and thus, its use effectively grants device ownership to the snap. That’s why we have this rigorous review process: to make sure we can achieve the purpose of snaps being a portable and secure method for distributing applications.

7

@emitorino I am pretty sure that will not work for me. The personal files would work for reading and writing the config file in a standard location (~/.config/quicknav/quicknav.json) but would not work for everything I need to do. As stated before, I need to be able to read existing directories and add new directories anywhere on the system. I do not know this before hand and therefore can not use the personal files interface because it has to be able to access all files in the users home directory. Thanks!

8

Hey @MrDogeBro,

Can you please confirm plugging the suggested interfaces is not enough for the quicknav use cases? The set of locations that are made accessible by those should cover standard locations for config files which is what your snap needs iiuc.

You could also make us of snap layouts to re-map some desired locations at /etc provided you know those in advanced.

9

@MrDogeBro - ping, this request cannot proceed without the requested information?

10

@emitorino, as previously stated, I am pretty sure that all of the suggested interfaces will not work for quicknav's use cases. It needs to be able to read and write files/directories anywhere in the users home directory, including hidden and non-hidden files, which obviously is not known before hand and cannot use the home interface. The removable media will also not work as that is used for accessing items such as usb sticks, not the users home directory. The system files interface will also not work for as that is not the location I am trying to access. Personal files interface will also not work as you need to know the read and write locations in advance, which I do not.

Please check out the GitHub repo if you need more information as to what quicknav is/does. Thanks!

11

@MrDogeBro hey,

I suggested several interfaces since you originally mentioned “jumping around different locations on your filesystem”, without restricting locations to the user’s home only. So if we limit the request to:

Then you do have the home interface which will grant you access to non-hidden files/folders. Hidden files/folders access can only be granted with the use of the personal-files interface, but as you said, you need to know the paths in advance and you don’t. Unfortunately, this is not a enough justification to request classic confinement.

12

@emitorino I need write access as well…which means the home interface will not work because as your documentation says, it only allows read access.

13

@MrDogeBro thanks for the follow-up in this thread. Unfortunately the need to read/write all hidden files in a user’s home directory is not a sufficient use-case to be granted the use of classic confinement as per the existing guidelines for classic confinement.

Whilst we understand you feel this is an important piece of functionality for this application, whilst the snap framework is flexible and can accomodate a large range of different application types, there are some which unfortunately it will not be able to be suitable to use with strict confinement. As such, whilst there is a requirement for classic confinement in this case, as it does not fit within one of the existing categories for the granting of classic confinement, we will not be granting the use of classic confinement in this case at this time for quicknav.

Thanks.

14

Ok…well…I disagree but ok. Also, basic things such as this should be allowed by default. For example, on the AUR (Arch User Repository), you can upload any package and when a user installs it it has a ton of permissions you guys don’t grant to simple CLI’s. The only thing that the AUR does is has you look at the install script and just verify that everything its going to do your ok with…