I've made some progress on this. It is all however excruciatingly
delicate, and this is not the first time that I have had to fix bugs of
this general nature. I'm beginning to wonder if I should be taking a
different approach. The whole problem here is that system hooks may
only be attached to by a single instance of any given package version;
this leads to the requirement that the AppArmor profile must point to
just the right instance, and we often run into trouble (of the
"launching application results in blank screen" kind) when trying to
move packages around between databases in various ways. Even with
regression tests, I'm worried that if I whack this mole it's still going
to pop up somewhere else. It's not clear that all the requirements are
truly soluble given the current design.
A more comprehensive answer to this category of problems, then, would
involve a slight tweak to the design of system hooks, though fortunately
an entirely backward-compatible one:
* We add a new substitution to the hook Pattern field that expresses which
database a package is in (the practicalities seem to suggest that a mangled
version of its path would be easiest, so ${db-path} expanding to
"usr_share_click_preinstalled" etc.).
* When this substitution is present, "click hook" would start running system
hooks for all instances of every package version.
* click-apparmor could then add that to its .hook file once it's ready,
perhaps becoming "Pattern: /var/lib/apparmor/clicks/${db-path}/${id}.json", or
a flat structure if that's easier. It would need to adjust its handling of
/var/lib/apparmor/{clicks,profiles}/ to cope with this, of course, and the
first system image upgrade with the new version of click might have to rebuild
all profiles on startup unless it's very clever, but that's comparatively minor.
* Now that profiles depend on the database path, aa-exec-click would need to
change its lookup to depend on the click database containing the requested
executable. Some care would be needed to make sure this doesn't slow down
application startup and make Ricardo cry; ubuntu-app-launch's desktop hook
could perhaps help with this, although that may not be necessary.
The result of this would be much easier to deal with in click, and would
be free of corner cases where there isn't obviously a single correct
answer.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371574
Title:
After installing clicks to /custom/click,
/usr/share/click/preinstalled version are still preferred
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1371574/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
