• Martin Kampas's avatar
    [sb2] prepare_exec: Do not discard changes to environment. JB#52287 · be954f53
    Martin Kampas authored
    Initially, my_envp equals to *new_envp, then it is modified. Those
    modifications are lost when *new_envp is used after that.
    
    The (possibly) discarted modifications to env. variables affect
    SBOX_DISABLE_MAPPING, SBOX_DISABLE_ARGVENVP and __SB2_REAL_BINARYNAME.
    
    Regarding SBOX_DISABLE_MAPPING, consider a host executable being
    executed by sb2 and trying to execute another host executable. With
    mapping not disabled, the other executable may be mapped to a different
    executable under target/tools root instead. In most cases this is likely
    to happen unnoticed. It breaks when there is an incompatibility between
    those, e.g., when the host executable is a GCC compiler trying to
    execute some of its internal tools - an i486 host compiler may end up
    executing an arm assembler this way.
    
    Trying to explain why *new_envp was used here, I don't believe it was a
    typo. At the same time I don't believe it was intentional to change the
    logic this way. I can't think of a reason to discard changes to the
    afforementioned env. vars. To me it seems inevitable to keep them set.
    Also, change was introduced with commit
    3f042f36 (Execs: Postprocess native
    dynamic binaries with C code) whose only objective seems to be
    reimplementation of some Lua code in C.  Maybe it was done to deal with
    some compiler bug and no one noticed it breaks things, as this only
    breaks in rather special cases like the one mentioned above.
    be954f53
Name
Last commit
Last update
rpm Loading commit data...
scratchbox2 Loading commit data...