Request classic confinement for qpkg

store-requests classic-confinement
1

[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.

2

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.

3

Hi Alex,

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:

  1. GNU GCC
  2. LLVM Clang, Clang++
  3. MSVC
  4. 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!

1 Like
4

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 :slight_smile:

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.

5

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.

Thanks

6

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).

1 Like
7

Hello alex,

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?

Audit log snippet:

Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.709:49287): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libz.so.1.2.11" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.709:49288): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libtinfo.so.6.3" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.710:49289): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libcrypto.so.3" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.710:49290): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.710:49291): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libm.so.6" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.710:49292): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Nov 18 14:48:13 convent kernel: audit: type=1400 audit(1731959293.710:49293): apparmor="DENIED" operation="open" class="file" profile="snap.qpkg.qpkg" name="/snap/core22/1663/usr/lib/x86_64-linux-gnu/libc.so.6" pid=3075757 comm="no3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

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.

Please grant classic confinement.

Thanks.

8

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.

9

I will need access to /usr/lib, /usr/include, and /var/log/nitrate.

10

Hi Alex!

Do you have any updates for my request for classic confinement?

11

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.

12

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.