[pkg-apparmor] Bug#782700: Please drop $remote_fs init.d dependency to allow running early

[intrigeri]

Hi,

[Seth, Steve & other folks who know about the Ubuntu phone: there are
questions for you below.]

Seth Arnold wrote (05 May 2015 18:50:50 GMT) :
> On Tue, May 05, 2015 at 06:22:29PM +0200, intrigeri wrote:
>> > Having the parser handle its own parallelism has been on our backburner
>> > for a long time; calling the parser once per directory with profiles is
>> > the end goal, e.g. apparmor_parser --replace /etc/apparmor.d/
>> > (This works now, just without DTRT parallelism.)
>> 
>> That would be awesome. Are there currently any resources allocated to
>> implement that in a known timeframe? (No pressure intended, I'm just
>> trying to gather all the information we need to decide what's the best
>> strategy to handle the problem at hand.)

> Currently no time is scheduled for this but I half-suspect it'll become
> a priority when Ubuntu Touch is moved over to systemd in the next few
> months.

In passing: Seth, any news on this one? :)


Regardless of the above, I'm coming back to this topic (reliance of
the initscript on /usr) thanks to https://bugs.debian.org/796589, that
asks us to provide a service file, which requires analyzing the
current dependencies of the initscript.

I've given a closer look at the reliance on /usr, and here's my
current analysis. Below, "->" means "calls", and "=>" means "my
current conclusion is".

- foreach_configured_profile() -> /usr/bin/xargs, when compiling the
  policy from scratch:

  - we could use busybox' xargs; it doesn't support -P, so we would
    need to manually compute the optimal -n parameter (number of
    profiles / number of CPU cores).

  - or, given it's only relevant for systems that boot with no policy
    cache at all, i.e. Live systems, that are unlikely to ever mount
    a remote /usr, we can decide to simply keep it the way it is until
    we're told it breaks a real life use case; IMO that's good
    enough. Thoughts?

- foreach_configured_profile() -> /usr/bin/xargs, when refreshing the
  policy cache: calls xargs with -P but without -n1, so likely only
  one apparmor_parser is run, and then dropping xargs shouldn't change
  anything. Same as above: relevant only for extreme corner cases,
  let's keep it this way and see. Thoughts?

- clear_cache(): xargs can be dropped thanks to `find -delete' (done
  locally), but `find' itself is in /usr; this function is called by:

  - initscript's start action ->
    handle_system_policy_package_updates(), iff. the apparmor package
    was updated since last time we start'ed; apparently, this was
    added to workaround
    https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1350673,
    that only affects systems with image-based updates (Ubuntu phone);
    this hack is not needed otherwise, and is a regression for remote
    /usr, so ideally it should be applied only on systems that use
    image-based updates; dear Ubuntu folks, how can we detect these
    systems in an initscript or unit file? (Ideally, something
    compatible with a Condition* service directive may be useful.)

  - initscript's stop action => OK (stop can rely on /usr)

  - initscript's restart action => OK (restart can rely on /usr)

- initscript's start action ->
  handle_system_policy_package_updates() -> compare_and_save_debsums()
  uses /usr/bin/diff => could use busybox diff, but really, again it's
  a workaround that should only be applied for systems that use
  image-based updates.

- foreach_configured_profile() uses /usr/bin/find; run by initscript's start
  action -> load_configured_profiles()
  => busybox find should be good

- initscript's restart/reload -> unload_obsolete_profiles()
  -> configured_profile_names(), that uses /usr/bin/sort
  => OK (restart can rely on /usr; but could use busybox sort)

- running_profile_names() uses /usr/bin/sort; called by:
  - initscript's restart action -> unload_obsolete_profiles()
  - initscript's teardown action
  => OK (restart can rely on /usr; but could use busybox sort)

- initscript's teardown action -> unload_obsolete_profiles() -> /usr/bin/comm:
  OK (teardown can rely on /usr)

Summing up, I see 2 problematic calls to /usr introduced by the Ubuntu
phone -specific workaround, one instance of `find' that should be
replaced with the implementation from busybox, and the rest should be
good enough as is. Which is good, because I don't plan to spend much
more time on supporting remote /usr here.

Opinions, better ideas? Should I just go ahead and it'll be merged
into the Ubuntu packaging?


Once we've addressed this first problem, then we can look at #796589
(meanwhile, feel free to add information there, e.g. about the plans
for native loading of the AppArmor policy in systemd, and how they
impact the unit files we'll need; better not mix the discussion with
this one, though).

Cheers,
-- 
intrigeri