Conversation

15 years later, the misguided glibc feature request to add a nonstandard "dlopen in-memory shared library image" function is still getting requests from folks who don't understand any of the technical details (specifically, why it wouldn't help) but have an ideological objection to temp files. 🤦

3
0
0

@hipsterelectron I suspect the hatred for them comes from Windows-land, where you can't unlink a temp file until you're done using it and where open files have nasty locking semantics. And where they're always on real disks.

On unix temp files are beautiful. Open, unlink, use, and never worry about stale ones getting left around. And on Linux, put them on tmpfs so there's no disk involved.

0
0
0

@dalias wait, what is the issue with trying to implement something like this? it feels like it should be totally doable (and easier than with PE, where this type of trick is/was a reasonably-common overly-clever/malcode thing)?

1
0
0

@r Implementing it is 100% functionally equivalent in resource usage, capabilities, etc. to writing out a temp file an dlopen'ing it.

What folks continually refuse to understand is that you cannot use the ELF image in-place in memory. It's not going to have the right access modes, likely isn't going to be aligned right, etc., and even if it were, most ELF objects are not mapped linearly but have different range mappings mapped at different relative offsets. Which can't be done with an existing in-memory copy.

1
0
0

@dalias seems like a suspect use case anyhow. i presume this is for some sort of management backdoor thing, but wouldn’t it make sense to drop the so on disks anyways so that you can look at them after?

0
0
0

@dalias ah, didn't realize that ELF objects also had different relative offsets -- somehow thought that they usually didn't (and only PE typically did)

1
0
0

@r On typical classic ELF shared objects without any fancy relro, non-executable rodata, etc. you typically have two mappings that overlap in the ELF image on the last page (one page mapped twice, partly as end of code/rodata and partly as beginning of rw data). Newer stuff is more elaborate.

0
0
0