@ijohnson hmm that is an interesting data-point - our current guidelines for classic confinement list the following categories:
Supported
- compilers
- IDEs
- juju helpers
- kubernetes tools requiring arbitrary authentication agents
- nautilus scripts
- programming languages
- public cloud agents
- tools for local, non-root user driven configuration of/switching to development workspaces/environments
- terminal emulators, multiplexers and shells
- HPC or orchestration agents/software for running workloads on systems without traditional users where the systems are otherwise managed outside of the agent (ie, the software simply orchestrates running workloads on systems and doesn’t manage the systems themselves). Note: many HPC/orchestration applications can run with strict confinement and classic should only be granted if snapd does not support the specific use case (eg, the need for user accounting).
In this case, nsntrace doesn’t appear to fit into one of these categories. I was going to suggest that it perhaps could be seen as something like a tool for local, non-root user driven configuration of/switching to development workspaces/environments since it switches to a new network namespace / environment to run the application. However, when I try and run the nsntrace deb it wants root privileges - I assume the snap is the same. In this case, it fails the non-root user driven part of that category.
In regards to etrace I feel that perhaps this did not fit the existing categories for classic confinement and so I wonder if @pedronis could comment on whether we need an additional explicit category for Tracing / development tools that wrap existing host binaries since to me the concept of IDE/compiler is perhaps a bit too limiting to cover this.