Classic confinement for `node` snap

store
1

Trying to to get the node snap published and I bumped up against this in build.snapcraft.io:

Error:(NEEDS REVIEW) confinement ‘classic’ not allowed. If your snap needs classic confinement to function, please make a request for this snap to use classic by creating a new topic in the forum using the ‘store’ category and detail the technical reasons why classic is required.

The way I understand it is that we need ‘classic’ for a tool like Node.js which essentially needs complete system access, unlike an application which ought to be confined.

2

FYI source is here https://github.com/nodesource/distributions/tree/master/snap

3

I’m +1 on this having initiated the conversation with Rod from the upstream project in the first place. As node/npm needs access to arbitrary locations, classic makes sense here.

4

For the reasons @popey explains its a +1 from me.

5

@niemeyer - can you please comment on Classic confinement for yarn so I can document the official position and process this request?

6

I am a +1 on classic confinement for NodeJS. Web applications will expect to access paths outside $HOME.

7

Also note that the Advocacy team has been working with @rvagg (who works at Node Source) on this.

8

This reasoning is different than what I expected. For example, in the aforementioned yarn request (unrelated to this request), it states “the node packages can define arbitrary tasks to run during installation. So yarn will need to execute external commands to be useful”, but you are saying that the classic confinement is needed for web applications. What are you thinking about, /var/www? (This isn’t to block the request but to capture the requirements for the future).

9

Both are valid reasons to approve node for classic in my view. I did not mean to suggest I was approving because I see arbitrary paths as a sole issue (and yes, of the /var/www variety), but that it alone is enough to warrant classic.

10

just dont forget that classic confinement means it completely rules the snap out for UbuntuCore usage (but i guess apps running there will simply use a node snapcraft plugin/part to bundle it and live with the duplication on disk)

11

I recommend we approve classic for the yarn snap, on the following basis:

  • This snap is oriented towards developers to install new functionality in their system which they need to understand and be responsible for in order to use.
  • There’s no possible confinement strategy that would allow all packages manipulated by the tool to work, since they carry arbitrary logic.
  • The tool is already popular and already being used by the community. Offering a snap maintained by upstream is an improvement over installing a third-party repository.
  • Offering a snap is also an improvement in terms of ensuring that such a security-sensitive tool remains up-to-date automatically and with serious bugs fixed.
  • This is a step towards encouraging people to confine their own applications, which are generated with the help of yarn.

Please note that all of these points are very specific to this case. We’re still learning about that sort of usage, and we should continue to keep an eye on it and discuss when new cases come up.

1 Like
12

Thanks Gustavo. Can you keep in the back of your mind other types of installer snaps? I think @Wimpress had ideas for MATE. I’ve granted classic to this snap (and the existing yarn snap) based on your feedback and have interpreted your comments as we’ll consider so called ‘installer snaps’ on a case by case basis for now.

1 Like