Please allow classic confinement for gmailctl

store-requests
1

Hi!

gmailctl (https://github.com/mbrt/gmailctl) is a CLI tool to create and maintain Gmail filters and labels. I would like to push it to the store, however gmailctl relies on files located in the user’s home folder for its configuration. Thus the snap needs (for now) to use “classic” isolation.

1 Like
2

What files and folders are these ? the home interface gives you access to all non-hidden files and folders of a user, the personal-files interface can be configured for specific hidden files and folders … there should be no requirement for classic for such a use case (and in fact the rules do not allow it)

3

Thanks you very much for your reply. I didn’t know about this interface.

However, the utility is written in Go, thus the home + personal-files interfaces doesn’t work, see Go HomeDir reads /etc/passwd, not $HOME

Also, the tool starts the user’s editor to edit the filter rules for Gmail. This is an issue with strict confinement since it cannot open the default editor set by the user (via EDITOR) neither get the user’s configuration of any editor that might be installed in the snap. Maybe there is also a workaround that I don’t know.

4

for the home dir issue there is:

regarding $EDITOR, snaps do transparently support xdg-open to open files with unconfined apps outside of their confinemet.

you could try to set EDITOR to xdg-open in the environment of your app in snapcraft.yaml, that would then (hopefully) hand the file path to xdg-open outside of the confinement, which in turn should run whatever application was defined for the mime-type of the file (an editor for txt files hopefully :slight_smile: )

1 Like
5

Thank you again for your help, I think I’m getting there. However, xdg-open doesn’t work for me:

snap run --shell gmailctl -c 'xdg-open $HOME/.gmailctl/config.jsonnet'
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: /usr/bin/xdg-open: Permission denied
6

thats likely because it cant see $HOME/.gmailctl … try with a file thats not in a hidden dir first…

7

Hm I don’t think that’s the actual issue…

$ snap run --shell gmailctl -c 'echo test > $HOME/test.txt && cat $HOME/test.txt && xdg-open $HOME/test.txt'
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
test
/bin/bash: /usr/bin/xdg-open: Permission denied
8

xdg-open requires the desktop interface IIRC. Make sure your snap has the following:

plugs:
  ...
  - desktop
1 Like
9

Indeed, xdg-open works now (for files in $HOME) :tada:

Also, I found an other issue. The tool copies the file to /tmp for editing, but xdg-open seems to have trouble opening files there and I don’t understand why:

snap run --shell gmailctl -c 'xdg-open /tmp/gmailctl-2323.jsonnet'
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
user-open error: request declined by the user (code 2)

Also I’m worried that all of this might not work in the end since xdg-open returns as soon as the editor is started while gmailctl expects the file to be edited when the command returns.

10

With regards to /tmp it is expected that trying to open these files outside the snap is failing, because the snap (each snap) has a separate /tmp directory (actually a subdirectory inside the host’s /tmp but is mapped to /tmp inside the Snap’s world view).

11

But this is not the issue here. The file was created from within the snap. This is not about sharing the /tmp folder with the host, just to edit a file that was created in the /tmp folder of the snap within the container itself.

12

This is not about sharing the /tmp folder with the host

I think it reduces to exactly that. Within the snap’s confinement you create a temp file in that snap’s /tmp.

But xdg-open runs outside the confinement, so it can’t see within it, at least not at the same path. I doubt this usage is considered correct, but you’d need to give xdg-open an argument like this:

xdg-open /snap/gmailctl/current/tmp/gmailctl-2323.jsonnet

You can see that system /tmp and the /tmp within a snap’s confinement are different, but based on your response I think you already know that:

root@kinetic:~# ls -lid /snap/core18/current/tmp/ /tmp
   1680 drwxrwxrwt  2 root root     3 Mar  9 00:44 /snap/core18/current/tmp/
5767169 drwxrwxrwt 24 root root 12288 May  5 21:40 /tmp

(corrections welcome. I’m still sorting out some of this myself)

13

Oh ok, that makes sense, since xdg-open runs outside of the container, it expects a valid path on the host.

@ogra it seems that the editor issue is a blocker here:

  1. the app cannot open files in /tmp to allow the user to edit the file
  2. Even if the code was changed to create the temp file in the $HOME folder (instead of /tmp) xdg-open would still return too soon (see this post).

Maybe there are other options I don’t know about but if not, is it possible to allow classic confinement for this snap?

14

does the app by chance respect the $TMPDIR variable (it really should) ? you could set $TMPDIR in your environment and point it to i.e. $SNAP_USER_DATA (which will be $HOME/snap/gmailctl/current/)

15

Yes, indeed it works perfectly fine! Thank you for your help :bowing_man:

However, 2. is still the last problem: xdg-open opens the editor on the host but soon after, gmailctl reports that no change was made and exits:

$ gmailctl edit
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
No changes have been made
$
16
  • Sou could try bundle an editor like nano into the snap explicitly and rely on the bundled nano
  • You could add a “press enter to continue” type message
  • You could consider using a tool like inotifywait to identify when the file has changed and block until it has, or recreate similar functionality by analysing the timestamps on the file yourself
17

Thanks for you help!

  1. This works without having to modify the CLI, which is good. However, it would force the user to use a single given editor without the ability to modify it. Also the user wouldn’t get its local configuration for this editor. For example, the first thing I did after installing gmailctl was to get a vim plugin for jsonnet files. I am uncomfortable with this solution because I would personally prefer to install the CLI using go get rather than snap install (and thus loose all the security/update features) if I had to use “bare” nano to edit the files.
  2. This would make the workflow less user friendly. I presume the CLI could detect the snap environment (via env var for example) and restrict this behaviour to it. However, this makes the code depend on the platform it’s running on.
  3. I think that doesn’t work as the user could save part of the file while still working on it. I’m also afraid it could break cross-platform compatibility with non-linux environments.
18

you wouldn’t have to hack your tool, but have EDITOR point to a script you ship … that in turn calls xdg-open, you can then put all the logic in there …

19

Re 1)
It is unfortunate but does open the option for you to bundle plugins that you think are relevant as well, though I’m not sure how easy that is.

Re 2)
You’d be able to check for the $SNAP variable amongst others to detect when you’re running in a snap,

Re 2/3)
While the user could save the file partway during editing it, the user could be using an editor that might return an exit early (for example, by adding a tab to an existing process and blocking attempt to spawn a new process), or might have some niche behaviour of going minimising to task tray / opening daemons / etc that otherwise block it from returning. Practically I’m unsure how common it might be for your user demographic, but I imagine it exists already. Asking explicitly might be the only real way of knowing they’re done.

Ultimately I think this might be the snap version of Turings Halting Problem, and there’s no “good” solution.

1 Like
20

Indeed that’s very smart, I will try that!