DuckPowered - Allow Installation and Auto-Connect request

store-requests
1

Dear @reviewers ,

I have created a snap called DuckPowered (registered name is duckpowered), whose purpose is to automatically underclock the CPU based on current usage.

My most recent upload just got automatically rejected due to the following issue (I have pressed the request manual review button):

human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (duckpowered-system-files, system-files)

I think what I have to do is request allow-installation of the system-files interface here.

My app requires this interface so it can modify /etc/default/grub to add intel_pstate=disable if the user consents.

The user is clearly warned and asked for consent before this permission is exercised with the following prompt:

(zenity prompt if GUI enabled) We found a driver called intel_pstate. It causes issues with DuckPowered. Press OK to continue.

And the next prompt says: Do you consent to disabling this driver? We will modify the kernel boot line

(shell script read command if GUI not enabled) [!] intel_pstate found! We will now disable the intel_pstate driver as it causes issue with DuckPowered, do you consent [Y/N]?

You can verify this by checking the source code here: https://github.com/Kotin-for-win/DuckPowered-Snap

May my snap be granted the allow-installation parameter?

Additionally, manually connecting interfaces will be frustrating for my users. May I request automatic connection for the following interfaces (justification provided):

cpu-control (The first line of my Store Description will be DuckPowered automatically underclocks your CPU when your workload allows, so the user is told about this permission. It is required for my app to actually function).

system-files as discussed above.

system-observe (this is required to gain information about the system to allow the dynamic underclocking. The second line of my Store Description will be This dymanic underclocking is possible because DuckPowered gets real-time information from your system to make an intelligent decision, telling the user about this permission).

I believe the x11 and wayland interfaces I’m using are already auto-connect.

You can find the full source code of my snap here: https://github.com/Kotin-for-win/DuckPowered-Snap

Thank you so much for reading through this request.

Have a great day and thank you again for your time,

Michael (foss-for-the-win)

2

Dear @ogra and @kyrofa,

I was wondering if you could please review this submission (it is for a FIRST Lego League competition, and we really need it approved by the competition deadline).

Thank you for your help!

3

sorry, i’m not a reviewer …

1 Like
4

+1 from me for auto-connect of cpu-control and system-observe since both are required and shouldn’t be surprising given the nature of this snap.

I am a bit wary about the system-files instance since /etc/default/grub is a very privileged file and modifications to this could result in the system being unable to boot / allow the snap to subvert the normal boot of the system and obtain full device control.

Instead if such a modification is absolutely required, it would be better to use the new kernel-module-load interface to use load: denied for this intel_pstate driver - then an assertion can be granted for just this module.

2 Likes
5

+1 from me for the auto-connection of cpu-control and system-observe, but I share @alexmurray’s apprehension on /etc/default/grub. I hadn’t considered the kernel-module-load interface, though, that’s a good idea.

6

Thank you so much for your replies @kyrofa and @alexmurray !

I have migrated to the kernel-module-load interface in the latest commit (building now, should take less than 5 minutes).

May I please have allow install and auto connect for the kernel-module-load interface?

Have a great day,

foss-for-the-win

7

+1 from me for the use of kernel-module-load scoped to:

    interface: kernel-module-load
    modules:
    - name: intel_pstate
      load: denied

One thing I note is that your snap yaml contains a bunch of redundancy in the interface declarations, ie:

plugs:
  duckpowered-cpu-control:
    interface: cpu-control
  duckpowered-kernel-module-load:
    interface: kernel-module-load
    modules:
    - name: intel_pstate
      load: denied
  duckpowered-system-observe:
    interface: system-observe
  duckpowered-wayland:
    interface: wayland
  duckpowered-x11:
    interface: x11

Can be simplified to just:

plugs:
 - cpu-control
 - kernel-module-load-deny-intel-pstate:
   interface: kernel-module-load
   modules:
   - name: intel_pstate
     load: denied
 - system-observe
 - wayland
 - x11

Also you still seem to have some references to a non-existent interface named duckpowered-system-files - this should also be removed.

+2 votes for auto-connect of cpu-control and system-observe - I have granted this now.

Let’s wait to see what other reviewers think about the kernel-module-load interface.

1 Like
8

Another +1 for that ^ . Nice job getting this strictly confined, @foss-for-the-win. Thanks for the hard work!

1 Like
9

Hi @foss-for-the-win,

Could you please simplify your snap.yaml as @alexmurray requested?

I am +1 as well for for use of kernel-module-load iface instead of system-files granting access to /etc/default/grub. So +3 votes for, 0 votes against, this is now live.

@foss-for-the-win I granted access to kernel-module-load but using the iface reference kernel-module-load-deny-intel-pstate which properly describes the access being granted. Once you update your snap.yaml and upload a new revision everything should work. Let me know otherwise!

1 Like
10

Dear @emitorino

I hope this message finds you well.

Thank you so much for dealing with this request - I’ll be sure to fix up that snapcraft.yaml, thanks again to @alexmurray for pointing out the easier method.

Thank you again to everyone involved in this thread for their time and helpful tips!

Have a great evening,

foss-for-the-win :smiley:

1 Like