Skip to content
Snippets Groups Projects
Select Git revision
  • android-7.1.2_r28_klist
  • master default protected
  • pie-cts-release
  • pie-vts-release
  • pie-cts-dev
  • oreo-mr1-iot-release
  • sdk-release
  • oreo-m6-s4-release
  • oreo-m4-s12-release
  • pie-release
  • pie-r2-release
  • pie-r2-s1-release
  • oreo-vts-release
  • oreo-cts-release
  • oreo-dev
  • oreo-mr1-dev
  • pie-gsi
  • pie-platform-release
  • pie-dev
  • oreo-cts-dev
  • android-o-mr1-iot-release-1.0.4
  • android-9.0.0_r8
  • android-9.0.0_r7
  • android-9.0.0_r6
  • android-9.0.0_r5
  • android-8.1.0_r46
  • android-8.1.0_r45
  • android-n-iot-release-smart-display-r2
  • android-vts-8.1_r5
  • android-cts-8.1_r8
  • android-cts-8.0_r12
  • android-cts-7.1_r20
  • android-cts-7.0_r24
  • android-o-mr1-iot-release-1.0.3
  • android-cts-9.0_r1
  • android-8.1.0_r43
  • android-8.1.0_r42
  • android-n-iot-release-smart-display
  • android-p-preview-5
  • android-9.0.0_r3
40 results

postinstall.te

Blame
    • Alex Deymo's avatar
      6cb2c893
      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
      History
      New postinstall domain and rules to run post-install program.
      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