tmp file ownership error

[StrongFennecs]

Not sure if this is an error or unexpected behaviour, but we are deving on a cluster with a shared /tmp folder. Additionally we are using an elixir library called erlexec. As part of the burrito process, running MIX_ENV=dev mix release and then running the burrito wrapped elixir program puts a libc-musl-##.so in /tmp owned by my user. The issue occurs when someone else on the machine wants to run the same burrito application (with a different user account). As the .so is not owned by them this generates a generic access denied error.

As part of the startup check burrito does find the libc

debug: The musl runtime file is already preset. Continuing.
debug: Size of embedded payload is: 13695240

but then runs into a permission error. It wasn't clear to me at first that this was permissions of the so - zig returns a generic

error: AccessDenied
/home/XX/zig-linux-x86_64-0.11.0/lib/std/os.zig:1803:19: 0x1085359 in execveZ (yy)
        .ACCES => return error.AccessDenied,
                  ^
/home/XX/zig-linux-x86_64-0.11.0/lib/std/os.zig:1846:57: 0x106c43a in execvpeZ_expandArg0__anon_9360 (xx)
    if (mem.indexOfScalar(u8, file_slice, '/') != null) return execveZ(file, child_argv, envp);
                                                        ^
/home/XX/zig-linux-x86_64-0.11.0/lib/std/process.zig:1153:5: 0x10325a8 in execve (yy)
    return os.execvpeZ_expandArg0(.no_expand, argv_buf.ptr[0].?, argv_buf.ptr, envp);
    ^
/home/XX/yy/deps/burrito/src/erlang_launcher.zig:109:9: 0x1031b66 in launch (yy)
        return std.process.execve(allocator, final_args, &erl_env_map);
        ^
/home/XX/yy/deps/burrito/src/wrapper.zig:145:5: 0x101f08b in main (yy)
    try launcher.launch(install_dir, &env_map, &meta, args_trimmed);

(XX = user account, yy the application - also this print out seems to be fixed to the user XX who compiled the code)

but after digging in and running it on different machines / changing ownership of the file in /tmp can make the program run or not.

Its easy enough to work around, but I feel the permissions should be checked - when appropriate -- too?

[doawoo]

Ahh this is a good catch.
Yeah the static musl libc is a large hack around worrying about the glibc version/configuration on the target machine. Our erlang releases are linked against it.

I feel like a better mitigation for this could be done. I'll assign myself to this and dig further to improve the experience for something like this.