Saying that the update “may take several minutes” is, I think, probably
not an effective solution to the problem of people powering off the
phone because it looks like it’s stuck. It doesn’t matter how long they
expect it to take: if nothing on the screen is changing, it would still
look like it’s
I like this idea. The fact that it takes a long time is less problematic
than the lack of user feedback. So, if there is any indication that the
phone is doing a normal thing and isn't dead, that's reassuring to the
user and also will stop people from resetting the phone, thinking it
died
Pat had the idea of implementing a variation of '8'. Essentially, look
inside the tar file and see if apparmor, click-apparmor or apparmor-
easyprof-ubuntu changed, then say something along the lines of "Security
policy will be updated after the device is restarted. This process may
take several
@Oliver, that is what I was getting at with pre-reboot-- there are many
things that could change that would impact policy and a full
implementation would have to account for all of them. The most likely
change is simple policy updates (ie, apparmor-easyprof-ubuntu) and that
is easy enough to
hmm, does generating on shutdown really make sense ?
what if i skip a few upgrades (which is a pretty common case, i.e. my moms
phone only gets updated when i visit her. and i know enough (non geeky) people
that simply ignore upgrade notifications altogether on their phones), meanwhile
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
@Jamie, I had assumed we would be using --skip-kernel-load. I was just
bringing up that policy versioning is not just about having different
versions of policy for different kernels but also about dealing with
failure cases.
--
You received this bug notification because you are a member of
@Pat, this is assigned to me but the changes needed are probably for
phonedations and possibly unity8. The click-apparmor patch for --with-
progress would be fast and wouldn't need our help (but we could do that
if needed). The security team would be happy to answer any questions and
advise on the
Adding click-apparmor task with same priority as the for canonical
system image.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click-apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350598
Title:
AppArmor policy
@John, I was thinking of using --skip-kernel-load so the policy is still
in the running kernel. I agree that versioned policy is safer though.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
Versioned policy is needed on touch if the compile is going to be done
before reboot. You do not want to blow away currently enforcing policy
and install the new version and then run into a situation where you
fail, or don't reboot. So at the very least for the failure case we
need to support
A few things I neglected to mention that John reminded me of are
1. if the kernel changes its apparmor feature set or the apparmor parser
itself changes how it generates policy, we'll still be running the old
kernel and parser. This will happen on an upgrade from 15.04 to 16.04
for example. If
@Pat, I think we actually want '8' for the phone. I mentioned what needs
to happen in the description. I'll mention it again here:
'8' can be implemented now to improve the user experience:
"
> Sorry for not being clear. The idea is that when the phone says that
> there is an update, the user has
@jamie what package needs to change to implement comment #4
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350598
Title:
AppArmor policy compile improvements
Status in
> Note, the current process isn't always 'no'! :)
Sure, I understand. But, even if the answer is "no" only some of the
time, it still means that the apparmor profiles interfere with our
normal development process. If I can't add a DBus method when I feel
like it, that's a pain. And, depending on
"In other words, we have a rather serious catch-22: the policy mechanism
is so expensive to reconfigure that it prevents us from adding new
features to services. Obviously, that's bad."
Note, the current process isn't always 'no'! :) At a minimum, you'd see
this when the image moves to a 16.04
Yes kicking off a policy compile as part of an update should be
possible. It certainly is for .debs, I am not sure of the exact details
for click or snappy.
As mentioned above, this compile could even be done as a low priority
background task so that the user update wouldn't pick up the cost.
As far as the profile change for the thumbnailer is concerned, it can
wait. It's not the end of the world if we can't get at the parameters on
the client side for the time being.
I don't want to belittle all the work that's already gone into the
policy compilation, so please don't take this the
I mentioned this to Marcus via irc yesterday and I think it is useful
context (leaving out parts that John already mentioned):
"07:48 so question: when we have that slow boot, what screen
is everyone left on to wait
07:48 blank? spinning ubuntu icom
07:49 blank
07:49 it is after the image is
Sure we want a good user experience.
We need to land the 2.11 version of apparmor which provides several
performance improvements. Its can be up to about 35% faster.
Another potential solution not discussed so far is kicking off a low
priority background process. This has its own issues, it
It would be ultra-cool to get a solution that has tolerable overhead on
first boot. In effect, if we can't touch the apparmor profiles, that
means that we can't evolve our code. Not being able to add a new dbus
method to a service can be a show stopper for new features, for example.
--
You
** Changed in: canonical-devices-system-image
Importance: Undecided => Low
** Changed in: canonical-devices-system-image
Status: New => Confirmed
** Changed in: canonical-devices-system-image
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
--
You received this bug
Adding 'canonical-devices-system-image' for the UX improvement work:
For Ubuntu Touch/Personal system-image based systems, investigate ways
to utilize the update tarball and compile policy before rebooting to
improve the user experience
** Description changed:
apparmor_parser can take a long
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Tags added: aa-parser
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350598
Title:
AppArmor policy compile improvements
Status in AppArmor Linux application
AppArmor upstream improvements for this are diminishing returns, so
marking as Low.
** Also affects: apparmor
Importance: Undecided
Status: New
** Changed in: apparmor
Importance: Undecided = Low
** Changed in: apparmor
Status: New = Triaged
--
You received this bug
** Tags added: aa-feature
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1350598
Title:
AppArmor policy compile improvements
Status in “apparmor” package in Ubuntu:
** Also affects: click-apparmor (Ubuntu)
Importance: Undecided
Status: New
** Changed in: click-apparmor (Ubuntu)
Status: New = Confirmed
** Changed in: click-apparmor (Ubuntu)
Importance: Undecided = Critical
--
You received this bug notification because you are a member
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
** Description changed:
apparmor_parser can take a long time to compile policy especially when there
is a lot of policy, so we want to utilize compiled cache profile as much as
possible. Cache files will have to be regenerated in the following cases:
* the kernel .features file is updated
34 matches
Mail list logo
