Once again, Snapcraft already granted classic confinement to ipfs-cluster and it is using ipfs daemons / apis / requirements underneath, so my understanding is that this request approval should be just a formality.
See prior discussion in: Classic Confinement Request for the ipfs-cluster Snap
Examples of errors include:
- inability to mount filesystem files to IPFS (
ipfs add --nocopyrequires direct FS access) – this means users with big files need to duplicate the required storage space or defeat confinement via sudo mount (see below) - CLI client and ecosystem tools are not compatible with confinement model. Security-sensitive operations that users can’t do over HTTP-RPC (key rotation, reading/changing remote pinning service access tokens) require direct filesystem access which is impossible with without Snap classic.
- Note: our users already defeat snap confinement by running
sudo mounthacks to restore basic functionality.
- Note: our users already defeat snap confinement by running
ipfs daemon falls under categories of
- public cloud agents (IPFS Swarm
https://docs.ipfs.io/concepts/glossary/#swarm) - programming languages (IPLD Data Model –
https://ipld.io/glossary/#data-model) - running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (self-organized relay system – libp2p Relay V2 (
https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md))