How to give my snap access to user files (images specifically)?

Firstly, I apologize if this isn’t the correct category. This is my first time creating snaps and using this forum :sweat_smile:

I recently created this command-line tool and thought I’d make it available as a snap to reach the widest user-base and ease of installation:

However, I’ve ran into a problem where the confinement: strict setting in snapcraft.yaml restricts the snap’s access to user files. Now given how the app needs access to images to convert them into ascii art, this is a bit of a problem. Furthermore, there is also a flag on the app which writes the ascii art in a .txt file, so I’ll need write access as well.

I’ve seen two solutions to this but don’t know which one is more appropriate.

Either I can use confinement: classic and wait for review, but it seems like an overkill for a simple cli app and I’ve seen posts where people say it won’t work for base: core18 ? Would appreciate it if someone could clarify this as well.

Or I can use personal-files interface to have access to the user’s $HOME directory, but apparently that seems to only work with specific directories inside the $HOME directory and I can’t choose the $HOME directory’s access itself (testing in --devmode gave me warnings).

I’m confused about the steps to take here. Would really appreciate if someone could guide me through this. Thanks for your time :slight_smile:

You can plug the home interface, which grants access to all the files in a users $HOME except those which belong to another snap (e.g, other snaps $SNAP_USER_COMMON and the like) or are top level hidden files or directories. This interface connects by default when declared.

1 Like

@James-Carroll Thank you! That seems like the perfect solution and it’s working just fine :slight_smile: The interface doesn’t give hidden images’ access yet, but I suppose that’s acceptable.

And this will not traverse mountpoints, correct? E.g. if Documents is a mounted nfs folder, that would not work?

Concerning an Ubuntu system with an AppArmor enabled kernel, then yes. AppArmor will notice it’s accessing a directory outside home and deny it, so it won’t work. Edit: See Daniels’s answer below, but bind mounts can still fix the symlink problem. If you really want to allow it anyway the best solution is to use bind-mounts which AppArmor doesn’t distinguish (and I assume xdg-desktop-portals can help here too for apps that can use them).

On other systems like Fedora with an SELinux backend or Arch where there may be no MAC enabled at all, I don’t know the specific answer but there’s a chance you might be able to cross that barrier, but I think it’d be considered a buggy implementation that might be “fixed” later. Someone more knowledgable might have a more specific answer.

That’s not necessarily true. If you directly mounted the nfs share to ~/Documents then it will be fine. If you replaced ~/Documents with a symlink to the nfs share mounted elsewhere in your filesystem tree then it will be denied (e.g. ~/Documents -> /nfs/Documents).

1 Like

Thanks for the correction Daniel, I’ve never personally had these problems so the info came from second hand information that I must have jumbled up.