reasoning: The compiler must be able to read/write arbitrary files. The package manager relies on HTTPS to download (and in the future upload) package specific to the Nitrate Programming Language ecosystem. Future work on the SNAP will embed a builtin debug utility that will attach to native processes via kernel APIs. In summary, due to the requirements for arbitrary file system IO (restricted to user permissions), network access to any remote host, coupled with the native process debugging facilities, and typical nature as with these package manager tools the SNAP interfaces are unfortunately inadequate for my purposes.
[YES] I understand that strict confinement is generally preferred over classic.
[YES] Iâve tried the existing interfaces to make the snap to work under strict confinement.
Can you please provide more details on what arbitrary the compiler needs to read/write? Where are they located? Also I am not sure that just because you plan a possible debug feature in the future it is suitable to grant classic confinement now. Please can you include specific details on what strict confinement is blocking at the moment for this snap? Thanks.
The compiler needs the ability to read from and write to arbitrary files based on the arguments it receives. This flexibility is crucial because the application is a CLI tool designed to integrate seamlessly into automated build pipelines, such as CMake. Arbitrary file I/O isnât just a convenienceâitâs a fundamental requirement for compilers. In fact, hereâs a list of well-known compilers that rely on this capability:
GNU GCC
LLVM Clang, Clang++
MSVC
Rustâs Cargo
This pattern of arbitrary file access is the norm among build tools, including CMake, making it a baseline expectation.
Beyond potential future debugging features, strict confinement also limits essential functionality right now. The application needs network access to download projects from GitHub, compile them, and install the results to locations outside the Snap sandbox. Moreover, the app includes a built-in Language Server accessible through the âlspâ sub-command, which requires unrestricted file read access to function properly.
Notably, clangdâanother Language Serverâwas granted classic confinement for similar reasons: it simply couldnât operate effectively under stricter constraints. Hereâs a reference: clangd on Snapcraft.
Given these factors, I believe classic confinement is not only justified but necessary to ensure the proper functioning of the tool.
Thanks for the updated informatino - I agree that in general build tools / compilers usually require unrestricted access to the host file-system but this is not always the case. Yes things like clangd/gcc etc do because they need to access headers and libraries from the host system - but there are other compilers which use just the files from a local project directory etc - in which case they should work under strict confinement. ie. most users local projects will live in their home directory and so the home interface is generally enough to support these cases.
It feels to me like qpkg fits more within this second category but you have still not provided enough information for me to determine this properly - can you please test qpkg under strict confinement and let us know what failures you observe? Also regarding network access, that is what the network interface is for
Please try with strict confinement and let me know if you see any failures and in that case can you provide the dmesg or journalctk -k output in that case which hopefully will show either AppArmor DENIED messages or possibly seccomp related denials and we can work to resolve those.
This is a fairly standard compiler tool. It takes a file (from somewhere) and converts it into an executable. This tool is supposed to âjust workâ. It should not be possible for my users to get a file system permissions error when trying to build an otherwise valid source that they have access to. If your strict confinement will grant read/write access to ANY file or directory the user ALREADY has permission to interact with, then i may explore that avenue. However, this is not the case from my understanding. I get errors âunable to open file in /opt/project-name/yada.nâ. I could add /opt to the whitelisted locations, but then it would defeat the point of strict confinement. Linux is centered around the filesystem, my compiler needs to work with it. For networking, I may look into the network interface.
My application very clearly fits into the âcompilersâ category. Please grant classic confinement as-is the norm or provide a 100% reliable workaround granting filesystem access as-if the app was installed via APT, such that user âfooâ with RWX permission to directory âbarâ can read/write/open directory âbarâ irrespective of where âbarâ is.
Not sure its relevant, but if strictly confined apps dont support symlinks that will be a major problem.
I also need it to work with removable media to compile projects on USBs.
The only directories i for sure dont need any access to are: /boot, /sys, /proc, and /run
This project is 100% open source, so if that helps with trustworthiness, great!
If it is possible and would improve security, i dont actually need the automatic SNAP update feature. I read thats the main reason that you folks are hesitate to grant --classic.
Also, not sure its relevant, but my application doesnât need the permission to delete files or spawn background processes (other then parallel compilation threads).
I have been troubleshooting the snap system-files interface. Basically it just doesnât work. The following directories failed to compile due to a SNAP confinement error:
/share/project-test-001
/root/project-test-002
/var/lib/project-test-004
There is probably more.
You had mentioned that âI agree that in general build tools / compilers usually require unrestricted access to the host file-systemâ. Why is that not the case for my application? Could you please explain why that is?
Itâs not reasonable to require users to ensure that all projects are located within /home/$USER/âŠ
I know some cases where projects will be stored in the /var/lib/app-name/extensions/source-code directory.
This is the nature of snap applications - they are sandboxed by default - and one of the existing unsupported categories for classic snaps (ie if a snap has this requirement it is not deemed a valid requirement for classic confinement) as per Process for reviewing classic confinement snaps is:
difficulty making strict confinement work
access to arbitrary files on the system due to developer/user inertia (home and removable-media is almost always sufficient, though personal-files and system-files may be used under certain circumstances.
So unfortunately even if there are use-cases you would like to support where such files are stored outside of $HOME or /media etc, if the snap itself does not actually require access to files from the host system (e.g. from /usr/include or /usr/lib etc like other compilers may) then strict confinement is the best option.
Can you please explain what files / groups of files exactly you need access to from /usr/lib and /usr/include? For /var/log you can use the log-observe interface I think.
My programming language has the capability and requirement to import local system header files written in the C language. Then trans-compiles them into a usable representation, thereby making them usable directly within the Nitrate source code. This is done to remove the need for an explicit foreign function interface.
Do to the compilerss need to import any local system header file, it needs read-only access to all files and directories in /usr/include.
The Nitrate compiler may link to local libraries included by the aforementioned mechanism. This necessitates the availability of read-only access to all files and directories in /usr/lib, /lib, and other lib aliases.
You are right on the /var/log/nitrate file access. I may not need that.
In summary, I do need generous access to the previously mentioned resources.
If there is no SNAP interface that provides this, please grant --classic.