Date: Thu, 27 Apr 2006 12:55:28 -0400
From: Derrell.Lipman@UnwiredUniverse.com
To: libc-alpha@sourceware.org
Subject: fopen() calls __open()
Message-ID: <vesvx8jj.fsf@oberon-mail.internal>
MIME-Version: 1.0

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


