© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
I fully agree to the case and to Bernds statement :-)
Hi and happy new year everyone btw.
I can recreate the case easily and confirm the confinement issue.
Rules are always only as good as they were used :-)
By extending use cases or by new version changing behavior the rules have to be kept up to date.
And this is one case we forgot but is easy to add.
If anyone can't wait for the update to land you can (always) add local rules to a profile with local overrides (allowing for e.g. custom configs).
In this case the following will get you going without loosing the confinement (which disable/complain mode would).
echo "/tmp/gpsfake-
The rule above got gpsfake going (no more apparmor blocks) in my case.
If you happen to find more by going deeper on that use case let us know.
As long as we have reasonable use cases we can easily add them unless they appear to be very non-secure. And in that case you can still use a custom rule for your config (=still no need to disable the profile)
While adding the rule I found that since Bernd and I added the profile to the package it was also accepted upstream. There were a few follow on fixes that we should integrate as well.
E.g. the gpsfake fix I just wrote is in there already.
We should use that file from upstream and contribute (or patch if needed) to that.
It also seems someone was very frustrated according to the comments in there.
=> https:/
But TBH many many common use cases work fine AFAICS.
I can understand the pain thou if you are not used to it and tried to add some better guidance to the upstream profile.
I've submitted a PR for this at:
https:/
And to use the upstream one in the packaging at:
https:/