- name: Stacer
- description: Stacer is an open source system optimizer and application monitor that helps users to manage entire system with different aspects, its an all in one system utility.
- snapcraft: Stacer/snap/snapcraft.yaml at snapcraft · QuentiumYT/Stacer · GitHub
- upstream: GitHub - QuentiumYT/Stacer: 🚀 Linux System Optimizer and Monitoring · GitHub
- upstream-relation: Owner / maintainer
- interfaces:
- hardware-observe:
- request-type: auto-connection
- reasoning: Stacer fetches hardware, CPU architecture, core counts, and frequency information dynamically by running commands such as
lscpu and reading stats in cpuinfo. It also queries block device layouts from /sys/block.
- network-observe:
- request-type: auto-connection
- reasoning: It reads real-time network RX/TX bandwidth usage statistics directly from files located in
/sys/class/net/<interface>/statistics/. It is shown in the dashboard for a global overlook.
- system-observe:
- request-type: auto-connection
- reasoning: A Processes tab displays a comprehensive process manager. It runs
ps ax to observe running tasks. Without this connection, it would only see its own process in the list.
- process-control:
- request-type: connection
- reasoning: This app has the capability to terminate, stop, or kill running system processes from its process list GUI via signal command utilities. The sandboxed snap needs this interface to send signals to external processes.
- removable-media:
- request-type: connection
- reasoning: Stacer queries total storage allocations and sweeps mount points using Qt’s
QStorageInfo::mountedVolumes(). This interface ensures Stacer can detect and list mounted external drives, SD cards, and USB media.
- dot-config-autostart (
personal-files interface):
- request-type: connection
- reasoning: Lists and manages startup programs in its Startup Apps page by reading and writing files under
/home/<user>/.config/autostart.
- dot-cache-clean (
personal-files interface):
- request-type: connection
- reasoning: Stacer’s system cleaning engine scans and empties the application caches residing under
/home/<user>/.cache with a user interaction and an exclusion list exists.
- dot-config-clean (
personal-files interface):
- request-type: connection
- reasoning: Same here for general application caches, logs, and state profiles tucked inside the
/home/<user>/.config folder tree to let users prune junk or clean configurations. This mainly include Cache & Code Cache from electon apps.
- local-trash-clean (
personal-files interface):
- request-type: connection
- reasoning: Quite the same here, for the feature to clean the user’s desktop trash and recycle bins located in
/home/<user>/.local/share/Trash.
- var-crash-clean (
system-files interface):
- request-type: connection
- reasoning: Stacer cleans system crash dumps and reports to recover disk space. It lists and removes files in the
/var/crash system folder.
- var-log-clean (
system-files interface):
- request-type: connection
- reasoning: Same here, it purges rotated log archives within
/var/log.
- var-cache-apt-clean (
system-files interface):
- request-type: connection
- reasoning: Same for the local package cache (cached
.deb files) kept inside /var/cache/apt/archives.
- apt-config (
system-files interface):
- request-type: auto-connection
- reasoning: Stacer has an APT Repository Manager tab allowing users to view, enable, disable, and clean up repository sources. It edits sources.list and sources.list.d, it’s a useful way to edit those sources but can be read only if needed.
Thanks for reviewing this particular app that’s been around for quite some years. As a maintainer of this original package to continue its legacy, I’m proposing a snap for people interested.
I know this is quite a lot of permissions, without those, the app looses a bit of it’s utility. I’d really like hardware-observe, network-observe, system-observe, process-control and removable-media to at least keep the dashboard usage of the app. Also apt-config, even if it’s read-only so we can keep the tab available and let people see the sources in a visual friendly way. Cleaning might be useful but system-files is not mandatory, so the personal-files might be enough to free some space 
Thank you for your understanding, feel free to ask me any questions about it!
This request has been added to the queue for review by the @reviewers team.
Hello @Quentium,
Thank you for the detailed request!
It is a +1 from me for granting auto-connection for the following interfaces, given they are well-understood access for system monitoring tools:
hardware-observenetwork-observesystem-observe
Regarding process-control, manual connection is allowed by default, there is no permission needed for this. However, if it is preferred I would be open to granting stacer auto-connection for the process-control interface, as it is granted for other system-monitoring tools such as htop. Just let me know if you would like to update the request or leave it as manual connection.
It is also a +1 from me for granting manual-connection for the following interfaces following successful publisher vetting, given this provides users the control enabling the more invasive, optional features, and the listed paths are not obviously owned by the snap:
- removable-media
- dot-config-clean (personal-files)
- local-trash-clean (personal-files)
- dot-config-autostart (personal-files)
This is a -1 from me for granting connection for the following system-files requests. While the functionality requested is reasonable, this would be broad access to provide for the non-central or optional features of the snap.
- var-crash-clean
- var-log-clean
- var-cache-apt-clean
- apt-config
What do other reviewers think?
Thanks!
Thanks for the detailed breakdown, that helps a lot.
+1 from me on auto-connection of hardware-observe, network-observe and system-observe. These are read-only observe interfaces matching the core advertised function of a system monitor and auto-connection is consistent with what we’ve granted similar tools.
As @elisehdy mentioned, process-control and removable-media allow manual connection by default, so no store declaration is needed for what you’ve requested.
On the personal-files requests: all of these need renaming to reflect the granted path rather than the feature (dot-config-autostart is fine; local-trash-clean should be dot-local-share-trash and so on). With renames, +1 on manual-connection ~/.local/share/Trash and given it’s a core advertised feature and manual connection, +1 on ~/.config/autostart, noting for the record that write access to autostart entries is effectively the ability to run code at the user’s next login, which users should understand when connecting.
I am -1 on write access to the whole of ~/.cache and particularly ~/.config. Blanket ~/.config access would expose credentials and configuration for every application the user runs (and includes autostart, subsuming the code-execution concern above with a far larger surface). I understand the cleaning engine targets per-app cache directories, but personal-files cannot express path wildcards and whole-tree access to defeat the home interface’s dotfile protections is exactly what the interface is not meant to grant.
Similarly -1 on the system-files write grants (/var/crash, /var/log, /var/cache/apt/archives) and on apt-config as requested. Beyond the sensitivity (write access to /var/log allows tampering with system audit logs and write access to apt sources is a root code-execution vector via a hostile repository entry), these paths are root-owned and a strictly confined user-session app has no supported privilege escalation path, so the grants would not actually make the features work. Since you noted system-files isn’t mandatory, I would suggest dropping these.
If you would like to keep the repository tab as a viewer, I would be open to a read-only system-files grant for /etc/apt/sources.list and /etc/apt/sources.list.d under manual connection
1 Like
Hello, thanks both of you for your detailed review!
I’d like to have process-control as an auto-connection, so it will enable a few extra feature out of the box for this application.
Regarding the rename, these are now dot-config-autostart, dot-cache, dot-config, dot-local-share-trash, var-crash, var-log, var-cache-apt-archives, etc-apt-sources. Got it for trash and autostart.
I understand about .cache and .config but sadly, apps (especially Electron apps) creates a bunch of junk Cache or Code Cache folder in the .config folder, and it’s necessary to explore all potential folders containing them (sad this is not mandatory to store in .cache tho). If these are not permitted, I’ll have to remove the System Cleaner feature on the snap app.
Also I haven’t requested (but it’s going to be a lot of requests), about the ability to clean specific dot folders /.npm/_cacache, /.bun/install/cache, /.m2/repository, /.gradle/caches, /.cargo/registry, /.expo/versions-cache, /.expo/native-modules-cache. But this might expand in the future and is probably too much. So maybe I should just discard System Cleaner.
I agree about cleaning system files, these are too sensitive.
I’d like to have a read-only access to /etc/apt/sources.list and /etc/apt/sources.list.d, it would be interesting to keep the tab to display those. Can this request be auto-connect as it’s read only @0xnishit ?
Thanks!
1 Like
Hello again @Quentium!
I agree with @0xnishit’s reasoning and +1 granting read-only access with manual connection for the etc-apt-sources system-files interface. While (hopefully) it is not the case for most configurations, there are still environments where read access to these paths could expose credentials, so in this case I lean towards emphasizing user-voice over convenience by keeping this access opt-in.
As for the System Cleaner feature, unfortunately functionality like this does not align well with snapd’s confinement principles given the widespread arbitrary file access necessary. If you are willing to deal with the maintenance overhead, we would likely be much more open to granting the request for a list of specific dot folders as described ( /.npm/_cacache, /.bun/install/cache,, etc). This would also be the case if you would be able to generate a list of specific paths under .cache or .config to request access for, perhaps for the most well-known, trash-creating Electron apps.
It is important to note that the access would still be manual connection given the lack of clear ownership of the folders. I do suggest submitting a new forum request with a link to this one if you do choose to move forward with retaining some System Cleaner functionality this way.
In summary, the current state of the request is as follows:
Interfaces to be granted auto-connection:
* hardware-observe
* network-observe
* system-observe
* process-control
Interfaces to be granted manual-connection given successful publisher vetting:
* dot-config-autostart (write)
* dot-local-share-trash (write)
* etc-apt-sources (read-only)
* removable-media (manual connection allowed by default)
Interfaces denied connection:
* dot-config
* dot-cache
* var-crash
* var-log
* var-cache-apt-archives
@Quentium, please let me know if you would like to proceed with the request as described above, or if you have any more questions. Thanks!
Hey, thanks for the recap. I didn’t know etc-apt-sources could contain credentials, I’m really into PPA and never seen that. A manual connection would make this page useless for most users because they might not be aware that they need to connect that themselves (not sure it is prompted while installing the app?).
Understood for System Cleaner, generating a huge list of .config/**/Cache and .config/**/Code Cache would be kind of a pain if it’s not auto connect haha, will probably disable this feature completely for snap users. I do not require the dot-local-share-trash in the end.
Isn’t it possible to allow an auto-connection about apt sources, given the fact it’s read only and probably less than 1% of Ubuntu users have credentials in it?
Regarding the recap, I’m alright with the following permissions
Hey folks!
Let me also give my perspective.
- I’m fine with the discussed auto-connections
- hardware-observe
- network-observe
- system-observe
- process-control
- dot-config-autostart: I don’t think we should grant write access to this directory, even considering manual-connection and/or successful publisher vetting. This enables a sandbox escape as has been discussed for
launchers (that asked for ~/.local/share/applications). I’m fine with read access here.
- etc-apt-sources: I’m fine if this is limited to read access and manual-connection. Most users actually accessing private ppas should be aware that this file may contain credential. I would possibly be ok with auto-connection given a successful publisher vetting, but I think this will be tricky in this case. For what I can see (please correct me), the original upstream project had little activity over the past years, and the repository you are maintaining is a fork. I think we will need to clarify what project is the distro consuming as of today to answer this question.
A manual connection would make this page useless for most users because they might not be aware that they need to connect that themselves (not sure it is prompted while installing the app?).
you can use snapctl is-connected to check whether a given interface is connected or not at runtime. Then, your application can act accordingly (i.e. show the user the instructions to connect the interface).
Hey, thanks for your review.
In my opinion, everything that is manual connection is for most users never enabled (because it requires a snap understanding ans is never prompted). I understand the sandbox escape etc, but honestly, i’m not sure this snap app would be the entrypoint for someone to add a specific entry in autostart. At this point, no apps should have this permission to write to ~/.local/share/applications.
Yeah, you’re right, Stacer has been abandoned. This app is a fork to continue the legacy of the software. It has been accepted in Debian and is now part of Ubuntu 26.04 (and many more distros). I adapted the APT Management to support newer deb 822 with sources files in this fork also.
Yes I can show a message on every tab that requires a manual connection in the code, my take was more about having a easier out of the box experience, considering the fact many people that chooses Ubuntu are not willing to use the terminal or tweak their softwares. I still wonders which audience targets Ubuntu tho.
Anyway, if the choice stays with a manual connection, I’ll just document it in the readme, people are always free to choose to run sudo apt install stacer.
