Requesting classic confinement for rogue-engine

Hi, I’m the creator of a WebGL creation engine.

This is a suite that includes an editor which requires access to the user system to create projects, install dependencies, bundle the user’s code and export their project for publishing.

The reason behind this is that these are node projects that can be located anywhere within the user’s file system.

As an example, the use case is similar to vscode’s.


1 Like

@BeardScript most users would likely store their projects within their home directory - as such I would assume that strict confinement with home and optionally removable-media plugged would provide sufficient access. In the case of vscode since this may use things like C headers / libraries or debuggers etc from the host system this makes more sense to require classic confinement - but it appears to me that rogueengine is more niche / specific and so would likely not require such broad access to the host system. Can you provide any more details?

Hi @alexmurray thank you for getting back to me. I am no that familiar with Linux so please, bare with me :grin:. I’m using child process to run “npm install/build/etc” and also to manage a local server running in the project’s folder.

I create a RogueProjects folder in the user’s “documents” by default but many people, myself included, use a secondary (usually bigger) drive to store their projects.

Would these things be possible with strict confinement?

Hey @BeardScript!

As @alexmurray suggested, you should be able to keep your snap strict (and therefore enjoy all the benefits of a stable runtime environment) and plug some of the supported interfaces based on your snap design and needs.

For example, you can use the home interface to access non-hidden files owned by the user in the user’s home ($HOME), including Documents, except other snaps and top-level dot directories. You can also use removable-media to read/write anything mounted in /media , /run/media and /mnt. Does removable-media satisfy you request of:

secondary (usually bigger) drive?

You just need to add these interfaces to the “plugs” of your application, here you can find the documentation about how to use such interfaces (and/or others) as needed. You can use snappy-debug to get suggestions/understand denials. If you run into problems, feel free to post the snappy-debug output here along with your questions and we are happy to help.

Please remember classic snaps are not installable on Ubuntu Core devices and also run in the global mount namespace, which means great care must be taken for the snap to work reliably across distributions.

@BeardScript ping, could you analyze the suggestions provided?

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

Sorry I missed your message. Thanks for getting back to me. Unfortunately, I’ll have to postpone this since it means I need to write more platform-specific code and this is something that wasn’t in my plans. I guess for now people will have to download the app from my website and since that’s a possibility this is no longer a priority. I’ll revisit this once I have time to spare. Thanks!

Ok I will remove this request from our internal queue - let me know when you can revisit it and I will add it back to our list.