To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
name: Nyctale
description: An honest and simple PC diagnostic tool designed for the general public. It analyzes the system to find out why a computer is running slowly or overheating, and provides a clear verdict along with actionable repairs.
upstream-relation: I am the upstream developer (publishing under “La Fabrik Numerique”)
supported-category: system monitoring / diagnostic tools
reasoning: To perform a complete and accurate system-wide diagnostic, Nyctale requires broad access to the system that cannot be achieved within the boundaries of strict confinement. Specifically, the application needs to:
Read metrics from /proc and /sys for all third-party processes (to identify which apps are consuming too much CPU or Memory).
Query journalctl to look for recent system crashes or critical kernel warnings.
Access the system’s package managers (apt, snap) to check for pending updates.
Scan and manage system-wide startup applications and background services.
Perform disk space analysis and cleanup across the whole filesystem.
Existing interfaces like system-observe, hardware-observe or log-observe are either insufficient or too restrictive for the broad, unfiltered access required to interact with arbitrary /proc states, read full system journals, and modify system startup states.
I understand that strict confinement is generally preferred over classic. I’ve tried the existing interfaces to make the snap to work under strict confinement.
Sadly this will completely deny classic confinement, see the second of the unsupported categories…
Please also see the *caveats" paragraph at the bottom of the page, your snap needs to be able to run on all distros you can install snapd on, to achieve this there is usually a lot of binary patching involved to make sure to keep the snap environment separate from the host at runtime…
Can you give us the denials you get when running your snap in strict mode alongside the snappy-debug tool, the access these interfaces provide should be broad enough for everything (we do have a lot of monitoring apps in the store that work well with strict confinement and snap interfaces)
I went through the app’s Linux code to check exactly what it touches, rather than guessing. Most of what Nyctale reads maps cleanly to strict-mode interfaces:
/proc/meminfo, /proc/uptime, /proc/cpuinfo, /proc/swaps, /proc/sys/kernel/osrelease → covered by system-observe
journalctl (recent boot history, error patterns) → covered by log-observe
I’m happy to move all of that to strict confinement with those three interfaces.
Two remaining pieces don’t seem to map to any strict interface, and I’d like your input on them specifically:
Package manager queries (apt/dpkg/dnf/pacman, e.g. pacman -Qkk to check for corrupted packages, and checking for pending updates). This is the exact capability flagged as unsupported in the review doc, and as far as I can tell there’s no strict-mode interface that exposes it at all — it’s intentionally excluded from the sandbox. Is that correct, or is there an interface I’m missing?
Browser configuration files (~/.mozilla/firefox/*/prefs.js, ~/.config/<browser>/*/Preferences) — read-only, used to report whether the browser’s memory-saver setting is on, since a browser left unoptimized is one of the most common causes of the slowdowns the app diagnoses. These are dotfiles, so the plain home interface doesn’t reach them. Would personal-files (manually reviewed, read-only, scoped to those specific paths) be the right path here, or is there a better-supported way to read browser prefs from a strict-confined snap?
If there’s no clean way to keep these two checks under strict confinement, I’d rather drop them from the Snap Store build specifically (keep them on the Windows/direct-download Linux builds) than misrepresent what the app can safely do under classic. But if personal-files is viable for point 2 and there’s a supported path for point 1 that I’m not aware of, I’d prefer to keep full functionality.
Let me know which direction makes sense and I’ll get a strict-confinement build with snappy-debug denials ready to share.
Looking at the app-center snap it seems to achieve that through talking to packagekit via the super privileged packagekit-control interface:
Perhaps that could be a path forward for you (not sure how likely it is that packagekit-control gets granted though, but probably more likely than classic confinement)
Yes, personal-files is the correct approach, you might not get auto-connect granted though (because your app is likely not the sole owner of these dirs) but your app can use snapctl is-connected ... to check if the interface is connected at runtime and notify the user to please connect it manually.
+1 from me for granting auto-connection to system-observe, hardware-observe and log-observe as they makes sense for the snap functionality
regarding packagekit-control, this is not a frequent ask and I’m not very familiar with the permissions it grants. I need to check it before making any statement about it.
For the access to ~/.mozilla/firefox/*/prefs.js, ~/.config/<browser>/*/Preferences via personal-files interface, I’m more inclined to only allow manual-connection, but this should be certainly fine
@lafabriknumerique would you mind sharing more details about how nyctale checks for corrupted packages, and checking for pending updates) on the different distributions?
@jslarraz Sure, here’s what nyctale actually does, distro by distro. Everything below is read-only / user-level, no root and no writes to the package DB:
Corrupted package detection
Debian/Ubuntu (apt): debsums -s — compares installed file checksums against the package’s recorded manifest. Requires the optional debsums tool to be present; if it isn’t, the check is simply skipped (reported as “not evaluated”) rather than failing.
Fedora/RHEL (dnf): rpm -Va --nofiles --noconfig — rpm’s built-in verify, restricted to non-file metadata/config so it doesn’t flag legitimate local config edits.
Arch (pacman): pacman -Qkk — pacman’s own file-integrity check.
Any other/unrecognized manager: skipped, reported as “not evaluated”.
None of these need packagekit-control or any privileged interface — they’re just read-only queries against the local package DB via each distro’s own CLI tool. No snapd-control needed either, since we shell out to the host tool directly rather than talking to packagekitd.
Pending updates / restart needed
We don’t currently enumerate the list of pending package upgrades — what we check is whether a reboot is required to apply an update already installed:
Debian/Ubuntu: presence of /var/run/reboot-required (written by apt/unattended-upgrades itself).
Arch: no equivalent implemented yet (no standard convention exists there).
So to directly answer the earlier packagekit-control question: we don’t touch it at all right now — everything above shells out to the distro’s native CLI (apt/dpkg/rpm/pacman tooling), read-only. Happy to go deeper on any of these if useful for the review.
In these case it might be possible to stage the tools needed (debsums, rpm, pacman) in your snap. From the man pages I believe that all these tools support the --root argument to point to the location of the file system of interest. In this case, the host file system is available in the snap runtime at /var/lib/snapd/hostfs. For debsums the command to run from the strict confined snap would be something like debsums -s --root=/var/lib/snapd/hostfs.
Please note that access to the host filesystem is blocked by the default confinement. To access it, you could possibly use the system-backup interface, which can be manually connected by the user.
Pending updates / restart needed
Debian/Ubuntu: presence of /var/run/reboot-required
similarly, you will need to inspect /var/lib/snapd/hostfs/var/run/reboot-required instead
In addition, if nyctale is a commercial product with an identifiable company behind it, it would be great if you could apply for a Verified Accounts. It helps the users to know that the snap is published by an official/trusted source and also will help reviewers to weight whether auto-connection might be acceptable/appropriate for the interfaces under discussion
Thanks a lot for the detailed pointers, this is exactly what we needed.
Corrupted package detection: implemented as suggested — staging debsums/rpm in the snap and running with --root=/var/lib/snapd/hostfs when the SNAP env var is set, falling back to non_evalue if system-backup isn’t connected (checked via snapctl is-connected system-backup). For pacman, we couldn’t find a documented --root-equivalent for -Qkk, so for now we simply skip that check under strict confinement rather than risk a false result — happy to revisit if you know of a supported way to point pacman at an alternate root.
Pending updates / restart needed: implemented — checking /var/lib/snapd/hostfs/var/run/reboot-required on Debian/Ubuntu. For Fedora/RHEL, could you confirm whether needs-restarting -r --installroot=/var/lib/snapd/hostfs gives correct results, or is there a caveat we should know about before we wire it in?
One more open question from our side: any update on packagekit-control as an alternative path for the update checks? Want to make sure we’re not duplicating effort if that ends up being the recommended route instead of system-backup.
Thanks again for the help getting strict confinement right.
--sysroot <dir>
Specify an alternative system root. This path will be prepended to all other configuration directories and any repository servers beginning with file://. Any paths or URLs passed as targets will not be modified. This allows mounted guest systems to be properly operated on.
For Fedora/RHEL, could you confirm whether needs-restarting -r --installroot=/var/lib/snapd/hostfs gives correct results, or is there a caveat we should know about before we wire it in?
my suggestion was an assumption based on that needs-restarting is a dnf plugin and dnf itself seems to support --installroot, but I’m not familiar with it. Maybe worth double checking with the upstream
One more open question from our side: any update on packagekit-control as an alternative path for the update checks? Want to make sure we’re not duplicating effort if that ends up being the recommended route instead of system-backup.
maybe, but we (reviewers) should have a more clear understanding of what can be achieved via packagekit as a regular user on the various distributions, and I don’t think we have the resources right now to be honest. I don’t know if packagekit is available in the default installation of all distributions mentioned above. For now I would consider it as a potential alternative for the long term
Thanks for the pointer on --sysroot — that’s helpful, we’ll test it if we resume the strict confinement work. For now we’re putting the Snap Store submission on hold to focus on other priorities, so we won’t be pursuing the Fedora/RHEL needs-restarting verification or the packagekit-control path in the near term. We’ll pick this back up and follow up with you if/when we return to it. Thanks again for your time on this.