I belive that nsntrace needs classic confinement because it traces the network activity of applications, and we cannot know the confinement needs for arbitrary binaries being traced.
If you take a look at our Process for reviewing classic confinement snaps, the need to launch arbitrary applications is not generally considered a supported use-case for classic confinement. So unfortunately this request cannot proceed as it is. You could ship any application (e.g. stage-package) in your snap but I assume this is not a valid scenario given what you have explained. Can you please confirm?
Hi @emitorino, I think that nsntrace fits into the class of utilities such as compilers/IDE’s, similar to my application etrace which was granted classic confinement usage, as per Jamie’s logic:
most notably that the snap can’t reasonably do its analysis while running under a strict mode runtime (needs access to host files).
As such, I think nsntrace should be granted classic confinement
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.
I think it’s fine to add a debug tools category with the following understanding:
the main reason to grant classic would be if they need, because of how they perform or because of the needs of the programs under debugging, to access potentially any file on the system
as usual we should be careful and reluctant to grant classic to programs that are open to external network access
Since we have agreed on extending the compilers supported categories to: “compilers and debug tools”, then the requirements are understood. @advocacy could you please proceed with the publisher vetting process?
Thanks, I split them out in their own category though. We might have to clarify some recommendations for them that are not shared with compilers themselves.
Granting use of classic. This is now live. @jonasdn could you please either request a manual review or upload a new revision so review-tools can run automatically again and your snap can be published? Thanks!