Hi, I’m helping Jupyter Labs to build snap ‘jupyterlab-desktop’ for JupyterLab Desktop.
The ‘classic’ confinement is needed for the app to work properly in cases when a file that is being edited is located in $HOME. JupyterLab Desktop is an Electron app that uses JupyterLab server as a backend. The server is shipped as a bundled Conda environment and installed into the snap’s user data directory. The backend, when works with a notebook file, creates checkpoints as hidden files next to the file. If confined as strict, a hidden file cannot be created in $HOME (only the existing hidden files are available via the interface system).
UPDATE:
To summarise reasons based on the discussion below:
JupyterLab Desktop is an IDE that allows a user to open a terminal (or run shell commands from a notebook). The strict confinement will limit the terminal experience to the confined environment.
JupyterLab Desktop creates hidden files next to the notebook as checkpoints. In the strict confinement, when, for example, a notebook is in $HOME, it fails to auto-save progress due to the Access Denied on the attempt to create a hidden file.
You can patch around the Jupyter backend code to alleviate the checkpoints issue to some degree. In the patches below I send them all of to $TMP as is their real purpose anyway, but more elegantly you could probably just drop the “.” and keep them proximate to the files they’re referencing.
This way you get to keep being strict with the benefits it brings. There might be reasons to use classic later, but we encourage people to stick to strict to help with predictable runtime environments and the other general sandboxing.
Thank you, I’ll have a look into that. The bundled environment comes as a conda.lock file and can (will) be updated independently. Hence, those patches would need to be reapplied and am not sure how sustainable that approach is. I agree that the server’s behaviour could probably be a bit more customisable, though (e.g. using an XDG location for checkpoints). That is something I discussed with the maintainers and it’s probably something we could not change now.
There is another issue too. In strict confinement, the behaviour of shell is different from classic. JupyterLab Desktop one can execute shell commands as part of a notebook (with a ! prefix), or just open a terminal session. In the latter case, for example, if a user has zsh as the default system’s shell, opening a shell fails unless you enforce bash via the SHELL variable for the snap. But even if done so, a user won’t get their shell of preference OR won’t be able to use shell as they would in a non-confined env.
If we kept trying for strict but the patches weren’t applicable at runtime, the general preference would be that you could use the personal-files interface as a workaround, however:
In my example snap that’s the behaviour I actually want (The entire snap would fall apart if the user was able to mix into the host environment). That specific snap has a horrible amount of complexity in classic confinement that doesn’t exist in strict; but the use-case for me makes perfect sense.
For your own snap which I’m understanding more as a general purpose IDE-like environment, there wouldn’t be a good solution for this problem, putting us back at classic. With that in mind though, it gives a clearly recognised category for classic as per
In your case it sounds like you’d be a mixture of:
compilers
IDEs
programming languages
tools for local, non-root user driven configuration of/switching to development workspaces/environments
With the criteria of:
access to files on the host outside the snap’s runtime (eg, /usr)
running arbitrary command (esp if user-configurable such as a developer tool to organize dev environments
Feel free to update your request since IMO this would now (likely) pass the criteria for classic confinement on the shell point assuming it’s critical to your use case. (I’m not a reviewer fwiw, so don’t take my opinions as gospel, but the usual review process is generally to encourage strict first and use classic if it doesn’t, which we’ve basically just done, so now the actual reviewers would have a solid basis to work from).
Thank you, I’ve updated the summary in the original message. As for the personal-files interface as a workaround, it only allows access to the specified files. Thus, it won’t work with arbitrary filenames created by JPD.
Apologies for the delay and thank you for investigating potential strict confinement solutions. As jupyterlab-desktop is an IDE, it fits within one of the supported categories for classic confinement as per Process for reviewing classic confinement snaps .
The publisher is already verified so I have granted the use of classic. This is now live
