libdl, no fdlopen function

connor horman
Thu Jul 23 02:42:58 GMT 2020

I can look into implementing it. Having it available would be quite useful
as I want to do runtime dso signature verification. I'd have to look at the
code that deals with the actual runtime loading and see where the name gets
turned into a file descriptor.

On Wed, Jul 22, 2020 at 22:32 Carlos O'Donell <> wrote:

> On 7/22/20 9:36 PM, connor horman via Libc-help wrote:
> > Hello libc-help list,
> > libdl and <dlfcn.h> provides access to the runtime linker to allow
> programs
> > to load new shared objects at runtime. However, it only provides the
> > capability to load shared objects by name.
> > The freebsd libc provides an fdlopen function (See:
> >, which
> allows
> > you to open a shared object from a file descriptor. This has numerous
> > benefits, including the fact that you can test properties on the file
> > descriptor before loading it as a shared object (for example, you can
> > validate some signature on the shared object, or, in a privileged
> process,
> > check the file permissions to see if its owned by root + suid). Using
> > simply dlopen, a program cannot securely do this, as attempts to do so
> > would be vulnerable to TOCTOU exploits. (On linux systems with the /proc
> > filesystem, it is possible to write code that solves this, however it is
> > entirely a hack.)
> > I was wondering if there was a reason why glibc does not provide similar
> > functionality (even behind #define _BSD_SOURCE). It would likely be less
> > hacky than using the proc filesystem (and less prone to
> open("/proc",F_OK)
> There is no strong reason why we don't have fdlopen(). I'd like to see it
> implemented. If someone wants to work on it that would be great.
> I would also like to see something like dlopen_from() implemented per this
> discussion:
> --
> Cheers,
> Carlos.

More information about the Libc-help mailing list