Skip to content
Snippets Groups Projects
  1. Aug 09, 2016
    • Alex Deymo's avatar
      Allow executing update_engine_sideload from recovery. · d63084d3
      Alex Deymo authored
      The recovery flow for A/B devices allows to sideload an OTA downloaded
      to a desktop and apply from recovery. This patch allows the "recovery"
      context to perform all the operations required to apply an update as
      update_engine would do in the background. These rules are now extracted
      into a new attributte called update_engine_common shared between
      recovery and update_engine.
      
      Bug: 27178350
      Change-Id: I97b301cb2c039fb002e8ebfb23c3599463ced03a
      d63084d3
  2. Apr 22, 2016
    • Andreas Gampe's avatar
      Selinux: Policies for otapreopt_chroot and postinstall_dexopt · e5d8a947
      Andreas Gampe authored
      Give mount & chroot permissions to otapreopt_chroot related to
      postinstall.
      
      Add postinstall_dexopt for otapreopt in the B partition. Allow
      the things installd can do for dexopt. Give a few more rights
      to dex2oat for postinstall files.
      
      Allow postinstall files to call the system server.
      
      Bug: 25612095
      Change-Id: If7407473d50c9414668ff6ef869c2aadd14264e7
      e5d8a947
  3. Apr 09, 2016
    • Alex Deymo's avatar
      Allow postinstall_file to be an entrypoint. · ac52f460
      Alex Deymo authored
      postinstall_file was an exec_type so it could be an entrypoint for the
      domain_auto_trans from update_engine domain to postinstall domain. This
      patch removes the exec_type from postinstall_file and exempts it from
      the neverallow rule to become an entrypoint.
      
      Bug: 28008031
      TEST=postinstall_example still runs as the "postinstall" domain on edison-eng.
      
      (cherry picked from commit a9671c6b)
      
      Change-Id: I2e1f61ed42f8549e959edbe047c56513903e8e9c
      ac52f460
  4. Apr 06, 2016
    • Alex Deymo's avatar
      Allow postinstall_file to be an entrypoint. · a9671c6b
      Alex Deymo authored
      postinstall_file was an exec_type so it could be an entrypoint for the
      domain_auto_trans from update_engine domain to postinstall domain. This
      patch removes the exec_type from postinstall_file and exempts it from
      the neverallow rule to become an entrypoint.
      
      Bug: 28008031
      TEST=postinstall_example still runs as the "postinstall" domain on edison-eng.
      
      Change-Id: Icbf5b262c6f971ce054f1b4896c611b32a6d66b5
      a9671c6b
  5. Mar 04, 2016
    • Alex Deymo's avatar
      New postinstall domain and rules to run post-install program. · a52b5618
      Alex Deymo authored
      When using the A/B updater, a device specific hook is sometimes needed
      to run after the new partitions are updated but before rebooting into
      the new image. This hook is referred to throughout the code as the
      "postinstall" step.
      
      This patch creates a new execution domain "postinstall" which
      update_engine will use to run said hook. Since the hook needs to run
      from the new image (namelly, slot "B"), update_engine needs to
      temporarly mount this B partition into /postinstall and then run a
      program from there.
      
      Since the new program in B runs from the old execution context in A, we
      can't rely on the labels set in the xattr in the new filesystem to
      enforce the policies baked into the old running image. Instead, when
      temporarily mounting the new filesystem in update_engine, we override
      all the new file attributes with the new postinstall_file type by
      passing "context=u:object_r:postinstall_file:s0" to the mount syscall.
      This allows us to set new rules specific to the postinstall environment
      that are consistent with the rules in the old system.
      
      Bug: 27177071
      TEST=Deployed a payload with a trivial postinstall script to edison-eng.
      
      (cherry picked from commit 6cb2c893)
      
      Change-Id: I49a529eecf1ef0524819470876ef7c8c2659c7ef
      a52b5618
  6. Mar 02, 2016
    • Alex Deymo's avatar
      New postinstall domain and rules to run post-install program. · 6cb2c893
      Alex Deymo authored
      When using the A/B updater, a device specific hook is sometimes needed
      to run after the new partitions are updated but before rebooting into
      the new image. This hook is referred to throughout the code as the
      "postinstall" step.
      
      This patch creates a new execution domain "postinstall" which
      update_engine will use to run said hook. Since the hook needs to run
      from the new image (namelly, slot "B"), update_engine needs to
      temporarly mount this B partition into /postinstall and then run a
      program from there.
      
      Since the new program in B runs from the old execution context in A, we
      can't rely on the labels set in the xattr in the new filesystem to
      enforce the policies baked into the old running image. Instead, when
      temporarily mounting the new filesystem in update_engine, we override
      all the new file attributes with the new postinstall_file type by
      passing "context=u:object_r:postinstall_file:s0" to the mount syscall.
      This allows us to set new rules specific to the postinstall environment
      that are consistent with the rules in the old system.
      
      Bug: 27177071
      TEST=Deployed a payload with a trivial postinstall script to edison-eng.
      
      Change-Id: Ib06fab92afb45edaec3c9c9872304dc9386151b4
      6cb2c893
Loading