Skip to content
Snippets Groups Projects
  • Alex Deymo's avatar
    a52b5618
    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
    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.
    
    (cherry picked from commit 6cb2c893)
    
    Change-Id: I49a529eecf1ef0524819470876ef7c8c2659c7ef