Skip to content
Snippets Groups Projects
  • 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