Classic Confinement Request

I am requesting classic confinement for my battery-info snap, a simple GUI tool designed to display battery information. Given its functionality and the permissions it requires, Classic confinement is necessary to ensure my app functions as intended.

Technical Reasons for Classic Confinement Despite defining plugs, which should theoretically provide access for reading battery status, my application encounter errors. Classic confinement is necessary to ensure my app can accurately and reliably read battery information without unnecessary restrictions.

Details of the Snap App Name: Battery Information Snap Name: battery-info Version: 1.0 Functionality: Displays battery information through a GUI.

Justification

My app @ https://snapcraft.io/battery-info does not access user files and is designed with strict adherence to privacy and security standards. I believe classic confinement is justified given the app’s specific requirements and its inability to function fully under strict confinement - — particularly due to the need to access power_supply data and to calculate the battery health

I look forward to feedback and approval for this request.

This request has been added to the queue for review by the @reviewers team.

Hey @sayedaliakhtarrizvi

Thanks for your request! Could you share the errors and denials you find when running your application as a strictly confined snap? (#askForInfo)

Thanks!

You did sadly not use the template you should be using for the request, so you are missing a bunch of mandatory information that is required.

One hard requirement is that your snap needs to fit into one of the listed supported categories from:

Please make sure to list which supported category you think your snap fits (note: it is unlikely that any of them fits for a battery meter)

The template you should have used can be found at:

(post deleted by author)

(post deleted by author)

(post deleted by author)

Please check the exact list of permitted categories in the post I linked, there is no such category as ā€œUtilitiesā€

This should be covered by the hardware-observe interface, what exact bits were not covered by it when you tied it ?

For these there are the opengl, x11 and wayland interfaces for low level access to these system components as well as the desktop and desktop-legacy interfaces for higher level access.

Have you used the snappy-debug tool with your snap ? It will tell you about available interfaces your application will have to use for functioning properly …

From the list of explicitly unsupported use cases from the first link I posted above:

Unsupported

  • difficulty making strict confinement work

So without a properly approved category and your snap even falling into an explicit unsupported use case, lets better look into the issues you are hitting with strict confinement. There are plenty of apps in the store with similar functionality as yours that get along with strict confinement, so please give us the errors you get in snappy-debug and we can help you make it work with the proper interfaces as a strict snap.

Yes I covered them already in my .yaml file. I know these and have used hardware-observeand desktop legacy the problem is only strict confinement that does not let me run the app when used classic it runs flawlessly

Have you also properly connected them with the snap connect ... command after installing your snap ?

If you have done this and still see issues, again, please provide the output of snappy-debug so we can see what is missing even when they are connected …

See it works flawlessly on Classic Confinement. But when I used strict confinement and snappy debug = AppArmor = Time: 2025-09-23T20:4 Log: apparmor=ā€œDENIEDā€ operation=ā€œopenā€ class=ā€œfileā€ profile=ā€œsnap.battery-info.battery-infoā€ name=ā€œ/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0A:00/power_supply/BAT1/manufacturerā€ pid=22927 requested_mask=ā€œrā€ denied_mask=ā€œrā€ fsuid=1000 ouid=0 File: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0A:00/power_supply/BAT1/manufacturer (read) Suggestions:

  • adjust program to not access ā€˜/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP0C0A:00/power_supply/BAT1/manufacturer’
  • adjust program to not access ā€˜/sys/devices/LNXSYSTM:[0-9]/LNXSYBUS:[0-9]/PNP[0-9]A[0-9]:[0-9]/device:[0-9]/PNP[0-9]C[0-9]A:[0-9]/power_supply/BAT[0-9]/manufacturer’

Yes, I understood that, but this is simply not an option …

Looking at the hardware-observe interface it should give you full read access to anything under /sys/devices with the rule highlighted below:

Can you try adding hardware-observe and also connecting it ? Else we might need to extend an existing interface to add access to this location …

I already did have a look plugs: - desktop - desktop-legacy - opengl - x11 - system-observe - hardware-observe
It works only in classic confinement not in strict that what I was asking for and I alreeady stated above This application requires classic confinement because it needs to access system-level information about the battery, which is not available in strict confinement. The snap also uses hardware observation to gather detailed battery information, which needs access to low-level system resources outside the constraints of strict confinement. Additionally, the snap interacts with system components such as X11 and OpenGL graphics that require classic confinement for proper operation.The app is read-only in nature and it does not access user files and is designed with strict adherence to privacy and security standards. I believe classic confinement is justified given the app’s specific requirements and its inability to function fully under strict confinement - — particularly due to the need to access power_supply data and to calculate the battery health…
But still instead of providing a solution you are giving replies like this.

Could you please clarify if you are an end user, a member of Canonical, or part of the development team? Also, kindly share your name and position.

Well,. no matter how often you state this, I gave you the rules for getting classic confinement granted above in the two links I posted, your app simply does not qualify to get it granted, pretty please read these pages …

Please check if the hardware-observe interface is actually connected using the snap connections battery-info command. A local test here confirms that an app using this interface has full access to all paths underneath /sys/devices and so should your app when making sure this interface is connected.

How is this relevant, we have pretty strict written down rules everyone can read and follow that explain exactly which set of application snaps can get classic confinement granted under which conditions and which can not, your application clearly does not qualify under these rules, it should not matter to you who points this out to you since you can verify what I am saying very easily by reading the two pages linked above…

FWIW … to see my name you just need to click on my avatar picture and yes, I do work for Canonical but again, this does not matter.

I’m just trying to help you getting your package fixed to work under strict confinement since you will not be able to get classic confinement granted by the existing rules …

I modified the code and switched to Strict Confinement. Thanks, Oliver, for the information. I truly appreciate you taking the time to clarify. My app is now working properly under strict confinement, adhering to all security policies.

1 Like