This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fopen() calls __open()


Hi all,

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!

Derrell


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]