Hi @shishirsub10,
Those are fair questions - let me explain…
Performix supports “launch workload” profiling. The user can freely type in command to profile. It could be a compiled application, an interpreted script, a build-system target, a shell pipeline, or a command that launches further child processes.
Users can select the working directory, provide environment variables, and optionally run the command through their configured shell. Performix passes this command to the selected profiling collector, which then launches and profiles it. The executable, arguments, interpreters, shared libraries, configuration, input data, and child processes are therefore determined by the user’s workload and host environment.
This execution model is a platform-neutral part of Performix’s architecture. Performix supports Linux, macOS and Windows hosts, and supported targets include both Linux and Windows on Arm. The same workload model described above is used across all platforms.
Under strict confinement, a launched workload remains subject to the snap’s mount namespace, AppArmor policy and seccomp policy. Connecting an observation or tracing interface does not make the user-selected child process run in a host-integrated context. Arbitrary host executables may not be visible, and a workload or its children may be unable to access the host resources and system calls they normally require.
We evaluated the suggested interfaces:
-
system-observe is useful for reading process and system information and can address process enumeration.
-
hardware-observe provides read-oriented access to selected hardware information in /proc and /sys.
-
system-trace provides privileged tracing access and may address some kernel-tracing requirements of individual collectors.
However, none of these interfaces provides arbitrary host-command execution or removes strict confinement from the workload launched by Performix. Therefore, even if they satisfy all the data-collection requirements of a particular collector, the fundamental launch-workload workflow remains incomplete under strict confinement.
Our primary reason for requesting classic confinement is the required ability to launch arbitrary user-selected workloads, as described above.