Request for system-files interfaces (hardlink to /etc/os-release) for auto-cpufreq

store-requests
1

There was a bug in auto-cpufreq for Pop OS, which was fixed by PR which creates hardlink to /etc/os-release.

Which works great for regular installations, however there’s an issue when app is installed using snap package. As Snap will not be able to point /etc/pop-os/os-release file to /etc/os-release and create hardlink on host system.

Hence could you please grant access to following plugs:

plugs:
   etc-pop-os-release:
    interface: system-files
    read:
    - /etc/pop-os/os-release

   etc-os-release:
    interface: system-files
    write:
    - /etc/os-release

As allow write access to this file will resolve above mentioned problem. If you have other suggestions how this problem could be fixed in Snap context, please let me know.

Thank you and looking for your reply,

Adnan

2

note that your snap should already have read access to these files via the /var/lib/snapd/hostfs path …

$ snap run --shell htop
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ ls /var/lib/snapd/hostfs/etc/os-release
/var/lib/snapd/hostfs/etc/os-release
$ cat /var/lib/snapd/hostfs/etc/os-release
NAME="Ubuntu"
[...]
$

(also, did you consider to ask the popos devs to fix this abnormality instead of trying to modify system files in /etc from an enduser app)

3

Access to /var/lib/snapd/hostfs/etc/os-release is allowed when the system-observe interface is connected.

4

@ogra @mborzecki just to clarify, how or would this allow me to create a hard link to point /etc/pop-os/os-release to /etc/os-release on host level outside of Snap container context?

5

nothing will allow you to create a hard link (this would be a really gross thing to do from an enduser app, since /etc/os-releae is a system configuration file used by many apps) but you can read/access the files and make your app act accordingly if you find the popos one …

this is in general really bad habit of the popos implementation, breaking with agreed standard locations for this file.

it should be fixed by them via using a proper /etc/os-release entry instead so that apps find the expected info in the agreed place … if it should be a hard link, it should be one made by the system installer or even better they should simply ship their own base-files package (which is the owner of that info on all debian based systems by design)

6

From a snap reviewers point of view, I do not feel this is an appropriate use of system-files - auto-cpufreq is not the clear owner of /etc/os-release so it would not be appropriate to grant write access to this file. -1 from me for write access to /etc/os-release for auto-cpufreq

7

In meantime a workaround has been coded/implemented, hence if it’s detected user is running on Pop OS and running auto-cpufreq a snap they will be notified how they can create this symlink outside of snap context.

Thank you for your review, but this request can now be ignored and closed.

8

Ok no worries - I have removed this request from our internal queue. Thanks.