[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object
vini.ipsmaker at gmail dot com
sourceware-bugzilla@sourceware.org
Mon Mar 16 20:11:02 GMT 2026
https://sourceware.org/bugzilla/show_bug.cgi?id=11767
--- Comment #55 from Vinícius dos Santos Oliveira <vini.ipsmaker at gmail dot com> ---
> So even if you fdlopen,
> the deps are still loaded by names!
FreeBSD added LD_LIBRARY_PATH_FDS 11 years ago:
https://git.quacker.org/d/freebsd-nq/commit/02d3b38e0a766bde374de052a2c65a095282f302?style=unified&whitespace=ignore-all&show-outdated=
The recent FreeBSD 15 release added rtld_set_var:
https://reviews.freebsd.org/D47351
So now you can combine rtld_set_var and LIBRARY_PATH_FDS to search for deps
(still by name) on (capsicumized/sandboxed) directory fds.
That's a solution for half of the problem, but I don't see the point of
discussing problems so far in the future (I mean it when I say that FreeBSD is
several years ahead of Linux when it comes to sandboxing) when community libc
implementations can't even catch up to the commercial ones (I'm looking at
Android which already provides fdlopen). I have more ideas to this problem, but
I'm only willing to discuss them when there's at least fdlopen in a released
glibc version.
fdlopen already has value even if you don't create any other extension on top.
Btw, FreeBSD dedups by the fd/fstat st_ino/st_dev:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277169#c5
> And also that lib itself can't be
> a dep of another, as once again you
> can't refer to an fd in DT_NEEDED.
That's the other half of the problem. This is more challenging. Again, I'm only
willing to discuss ideas when I at least see the basic thing (fdlopen on a
released glibc version).
Again: fdlopen already has value even if you don't create any other extension
on top.
> I am very interested in sandboxing
> under linux, so if there is some
> place to discuss things with you
Send me an email. We can continue there.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list