This is the mail archive of the
mailing list for the glibc project.
fopen() calls __open()
- From: Derrell dot Lipman at UnwiredUniverse dot com
- To: libc-alpha at sourceware dot org
- Date: Thu, 27 Apr 2006 12:55:28 -0400
- Subject: fopen() calls __open()
- Reply-to: Derrell dot Lipman at UnwiredUniverse dot com
I'm on the Samba team, responsible for the client library, which provides
Unix/Linux access to Windows networks. As an example program for using that
library, I have an LD_PRELOAD library that traps primitive file system calls
and if the path is to /smb/... it maps to the Samba client library; otherwise
to RTLD_NEXT (glibc). This all works great for most programs. For the
primitives that are mapped, three versions of each are mapped: 0, 1 and 2
leading underscores (if such functions actually exist in the C library). For
example, I map open, _open and __open (assuming they exist in the library).
The problem is that some internal non-primitive functions like fopen()
directly call __open(), and (from my read of the source, it appears that)
__open() is aliased to open() such that fopen()'s call to __open() isn't
trapped by my preload library. This means that if the file
/smb/SERVER/SHARE/filename is open()ed, the file on the remote Windows server
gets properly opened, but if that same file is fopen()ed, no file is found
because the internal __open is called.
I know that I could override fopen() and friends (including any other "high-
level" functions that call internal versions of primitive functions), but
there's a fair amount of code involved in those, and reimplementing or
copying them for the sole purpose of compiling them such that they use the
overridden open() call seems a lot like overkill.
What can I do to cause fopen() in glibc to call the open() or _open() or
__open() in the preload instead of the internal __open?
Thanks in advance for your help!