Problem Description:
Security Center (channel latest/stable, occurs on other channels too) shows me Ubuntu Pro is not available on this system as it’s only supported on LTS.
Perfect, thanks for pointing out. Indeed running command fixed the issue.
Perhaps the message should be changed to more precise like “Security Center could not access Pro status“ or “Security Center has no access to system status“…
Interesting, but that would require a Snap aware program to be able to show the actual cause, as it seems. I don’t think Security Center was designed that way. And even with snapctl it wouldn’t be able to tell why it failed, IIUC. We can also use aa-notify to get notified, whenever something prohibited is accessed. But it’s not exactly straight forward to make the connection between the messages and how the denial manifests in the program in question.
Well, indeed this assumes that the packager knows they need a certain interface for access to a certain system resource (which they usually do though because they added that interface in the first place when producing the package), then checking if the interface is connected from inside the snap is possible so they could show some popup to the user to manually connect it …
Though as mentioned, the request for auto-connection has already been filed and as soon as it is granted by the security team the interface will just connect and no action will be required on either side.
My statement was aimed at the request for a more targeted error message. Security Center simply sees some test fail – probably that lookup for ‘LTS’ in the Ubuntu version string, mentioned in the linked thread – and doesn’t have provisions to examine the cause.
What you are suggesting is for the snapcrafter to provide a means to detect a packaging bug, essentially, which is kind of a circular dependency. Why not simply fix the packaging bug? And it usually requires in-depth knowledge of the software to be confined. The issue at hand is caused by a simple oversight during packaging. The error condition can probably approximated by something like chmod 0 /etc/os-release, which would result in a permission error on read requests. Other than having explicit provisions to listen for AppArmor denials, how would Software Center, or any software, for that matter, be to know if that failure is because of sandboxing and thus a missing Snap interface connection, or if it’s simply a file permissions issue? That’s what I didn’t care to explain in detail.
However, I’ve just realized that one could make use of Prompting Client in conjunction with this. If some app were trying to access a denied resource, there’d be a prompt for the permission to do so.
The packager simply understimated how long an autoconnect request usually takes to be granted (IIRC we set a two week period for these requests to get two approvals from the reviewer team) it was only filed 6 days ago …
Methinks there is a connection to some release of a popular Linux distro, that coincided with that.
IIRC, the bug report mentioned as much to the effect that it was, in fact, an oversight. I mean, who’d have thunk that Security Center would need the system-observe interface?
Plus, it’s not like it is bleeding edge. It’s just that nobody seems to have thought of the auto-connect before the release to the general public.
BTW, so I am not misunderstood, this is not a dig at Canonical or Ubuntu, in any way, shape or form. Everybody is allowed to make mistakes, and an oversight ranks among the easiest ones, so it’s easily forgiven.
You know, you’ve done a cracking job, when that kind of issue is the only one to come up after such a major milestone!