As part of the BootStack DevOps team, I would like to officially request approval for auto-connect for system-files and snapd-control interfaces into the snap package called software-inventory-exporter .
The BootStack team will have a centralized report for all customers clouds and for that, we need to fetch information about all debian packages and snaps installed on machines, so we can detect security issues on packages versions and to be sure that the same version of packages are installed thru the cloud. In order to do that, we need the classic confinement to retrieve those information from the “host” machine.
Initially I used the classic approach, but it was said to turn it into strict confinement.
It is a shame there is no snapd-observe (cc @pedronis@mvo) or similar interface since granting snapd-control just to list the available snaps is quite an overreach in terms of privileges. However, this is still better than classic confinement. So +1 from me for use-of snapd-control for software-inventory-exporter.
Can you please give some more details on the system-files usage here? What paths are being requested with what permissions, and what name is used for the system-files interface? Thanks.
We just need read access to those folders in order to be able to list Debian packages installed in the machine by running dpkg -l. The name used is apt-dpkg-db and the solution is heavily based on the cvescan snap. Thanks
I also think granting snapd-control means granting a lot of privileges this snap does not really need. What exactly software-inventory-exporter needs in terms of installed snaps? If it is for inventory purposes, could it get the information by reading (only) from snaps system directories such as /snap instead?
In the meantime, I am +1 as well for the use of system-files using the iface reference apt-dpkg-db with read only access to directories related to deb packages.
While this is a very ugly hack, one could use a system-files interface with read access to /var/lib/snapd/state.json to then parse it for the info … (this would not only only be hacky but also quite a bit of development to get the parsing right indeed, but would prevent snapd-control usage)
The tool would only need to show what snap list does, e.g. name, version, rev, tracking and possibly change-date - that will be very useful when troubleshooting issues and correlate that to recently refreshed snaps.
I agree that snapd-control is quite overreach in terms of privileges and in the short term we can use the solution that @ogra suggested, but it looks fragile and I guess that there is no commitment on keeping the state.json file in the same format in the long run. We can use this solution to unblock our workflow and have the snap published, but ideally it would be good having a more stable solution like @alexmurray suggestion.
I’ve opened a new bug#2012539 on the snapd project to keep track of it.
in the latest version(1.0.1.dev2+ga3330e2) of your snap software-inventory-exporter , it is asking for the autoconnect request on the following file locations
/snap dir location is not approved as per the discussion above. I have rejected this version. Please update the version with the required limited number of files approved above.
Thanks for the feedback. I was not sure if I should open a new store-request because of this change.
As you said, now I’m just using system-files interface and the plug name changed from apt-dpkg-db to snap-apt-dpkg-db to have a better name that fits with the snap needs:
The reason that I’m adding /snap is because state.json doesn’t provide the version of the charm and this is an important metric to us. What I’m doing to get the version is reading the file /snap/{snap}/current/meta/snap.yaml of every installed snap in a machine.
