Open StrongFennecs opened 5 months ago
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.
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 callederlexec
. As part of the burrito process, runningMIX_ENV=dev mix release
and then running the burrito wrapped elixir program puts alibc-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
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
(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?