libdl, no fdlopen function

connor horman chorman64@gmail.com
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 <carlos@redhat.com> 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:
> > https://www.freebsd.org/cgi/man.cgi?query=fdlopen&sektion=3), 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)
> > -> EACCESS/ENOENT).
>
> 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:
> https://sourceware.org/pipermail/libc-help/2020-January/005107.html
>
> --
> Cheers,
> Carlos.
>
>


More information about the Libc-help mailing list