From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4464DD3E.6040203@altlinux.org> Date: Fri, 12 May 2006 23:08:46 +0400 From: Alexander Bokovoy User-Agent: Thunderbird 1.5 (X11/20060225) MIME-Version: 1.0 To: ALT Devel discussion list Content-Type: multipart/mixed; boundary="------------060501010506030305040606" Subject: [devel] [Fwd: [(nowhere)] fopen() calls __open] X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2006 19:09:06 -0000 Archived-At: List-Archive: List-Post: This is a multi-part message in MIME format. --------------060501010506030305040606 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable =E9=CE=D4=C5=D2=C5=D3=CE=C1=D1 =C4=C9=D3=CB=D5=D3=D3=C9=D1 =D0=CF =D0=CF=D7= =CF=C4=D5 =D4=CF=C7=CF, =CB=C1=CB =C4=C5=CC=C1=D4=D8 "=D0=C5=D2=C5=CB=D2=D9= =D4=C9=D1" =C6=C1=CA=CC=CF=D7=D9=C8=20 =CF=D0=C5=D2=C1=C3=C9=CA =C4=CC=D1 glibc. =F7 =D3=D7=C5=D4=C5 =C2=CC=C9=D6= =CE=C5=C7=CF =C9 =D3=D2=C5=C4=CE=C5=C7=CF =C2=D5=C4=D5=DD=C5=C7=CF =CF sm= bsh =C9=20 =C1=CE=C1=CC=CF=C7=C1=C8, =D0=CF=C8=CF=D6=C5, =D0=D2=C9=C4=C5=D4=D3=D1 =DA= =C1=C2=D9=D4=D8. =F7=D3=C5 =D6=C5, autofs/automount =C2=CF=CC=C5=C5=20 =C7=D2=C1=CD=CF=D4=CE=D9=CA =D0=CF=C4=C8=CF=C4. -------- =E9=D3=C8=CF=C4=CE=CF=C5 =D3=CF=CF=C2=DD=C5=CE=C9=C5 -------- =F4=C5=CD=C1: [(nowhere)] fopen() calls __open =E4=C1=D4=C1: Fri, 12 May 2006 14:05:20 -0400 =EF=D4: Derrell.Lipman@UnwiredUniverse.com =EF=D4=D7=C5=DE=C1=D4=D8: Derrell.Lipman@UnwiredUniverse.com =EB=CF=CD=D5: Andrew Tridgell =EB=CF=D0=C9=D1: samba-technical Hi Tridge, Reference our conversation a few weeks ago about fopen() and smbsh: I thought you might be interested in this thread where I hoped to get som= e useful information from the glibc folks about how to have fopen() work properly with smbsh. As you can see from this thread, it's likely to be = a non-trivial effort... Derrell --=20 / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/ --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-2.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-2.tmp" Subject: Topics Topics: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() Re: fopen() calls __open() --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-3.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-3.tmp" 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: 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 --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-4.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-4.tmp" Date: Thu, 27 Apr 2006 10:03:02 -0700 From: Ulrich Drepper To: Derrell.Lipman@UnwiredUniverse.com CC: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <4450F946.6030909@redhat.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=====-=-=" --=====-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Derrell.Lipman@UnwiredUniverse.com wrote: > 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? Nothing. Once a call enters glibc it won't leave it until it's down. Exceptions: the malloc functions. Everything is completely opaque and that won't change. --=20 =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro St = =E2=9E=A7 Mountain View, CA =E2=9D=96 --=====-=-= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEUPlG2ijCOnn/RHQRAkP1AKCoppgcC3ED6IAPsDnkvFvNZWrm0QCgh1x2 TEPrztIc6KWT1bYwfPCrruM= =dfId -----END PGP SIGNATURE----- --=====-=-=-- --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-5.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-5.tmp" Date: Thu, 27 Apr 2006 13:06:35 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <8xprx810.fsf@oberon-mail.internal> References: <4450F946.6030909@redhat.com> MIME-Version: 1.0 Ulrich Drepper writes: > Derrell.Lipman@UnwiredUniverse.com wrote: >> 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? > > Nothing. Once a call enters glibc it won't leave it until it's down. > Exceptions: the malloc functions. Everything is completely opaque and > that won't change. Ok. Thanks for the response. I'm a bit confused as to why certain functions are weak and allowed to be overridden (e.g. open, __open) but not higher-level functions that use them. It seems a bit inconsistent, but I assume there's a reason. If there's some prior thread that explains this, I'd sure appreciate a pointer to it. Otherwise, might you be able to explain why primitives can be overridden but not such that the users of those primitives within the library use the overridden versions? Thanks! Derrell --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-6.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-6.tmp" Date: Thu, 27 Apr 2006 10:43:08 -0700 From: Ulrich Drepper To: Derrell.Lipman@UnwiredUniverse.com CC: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <445102AC.5090505@redhat.com> References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=======-=-=" --=======-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Derrell.Lipman@UnwiredUniverse.com wrote: > I'm a bit confused as to why certain functions are weak and allowed to be > overridden (e.g. open, __open) Forget about weak. The is no difference in the treatment of weak and strong symbols when they are defined in DSOs. They are all the same. The aspect interesting for you is exported or not. No internal libc call except those to the malloc functions references names which are exported. --=20 =E2=9E=A7 Ulrich Drepper =E2=9E=A7 Red Hat, Inc. =E2=9E=A7 444 Castro St = =E2=9E=A7 Mountain View, CA =E2=9D=96 --=======-=-= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEUQKs2ijCOnn/RHQRAlGLAJwLv/XjQPFBwXltsOJ0CKSgbuVuNQCeJkXp bzhGu/ARFzSNXOeL5sZramY= =dxnk -----END PGP SIGNATURE----- --=======-=-=-- --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-7.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-7.tmp" Date: Thu, 27 Apr 2006 13:55:06 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> MIME-Version: 1.0 Ulrich Drepper writes: > Derrell.Lipman@UnwiredUniverse.com wrote: >> I'm a bit confused as to why certain functions are weak and allowed to be >> overridden (e.g. open, __open) > > Forget about weak. The is no difference in the treatment of weak and > strong symbols when they are defined in DSOs. They are all the same. > The aspect interesting for you is exported or not. No internal libc > call except those to the malloc functions references names which are > exported. Ok. So that means that if I want applications running over the Samba wrapper (smbsh) to be able to call fopen() and have them open files on the remote Windows server as currently works with open() and __open(), I need to put an implementation of fopen() and friends into the LD_PRELOAD library as well. I'm not looking forward to lugging around all that extra code, but it sounds like that's my only choice. If you have any other suggestions for me, I'd certainly like to hear them! Thanks for your help, Derrell --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-8.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-8.tmp" Date: Thu, 27 Apr 2006 14:04:17 -0700 From: Paul Eggert To: Derrell.Lipman@UnwiredUniverse.com Cc: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <87lktqu3vy.fsf@penguin.cs.ucla.edu> References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> MIME-Version: 1.0 Derrell.Lipman@UnwiredUniverse.com writes: > If you have any other suggestions for me, I'd certainly like to hear them! You're not alone in having this problem. One approach is to supply a your own modified libc that addresses the problem. For an example of this, you might take a look at Plash ; in particular see the 2nd FAQ in . An idle thought: perhaps you can even use Plash's libc, or come up with a slightly-modified libc that both Plash and you can use. --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-9.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-9.tmp" Date: Fri, 28 Apr 2006 10:43:35 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: Paul Eggert Subject: Re: fopen() calls __open() Message-ID: References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> <87lktqu3vy.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 Paul Eggert writes: > Derrell.Lipman@UnwiredUniverse.com writes: > >> If you have any other suggestions for me, I'd certainly like to hear them! > > You're not alone in having this problem. One approach is to supply a > your own modified libc that addresses the problem. For an example of > this, you might take a look at Plash ; in > particular see the 2nd FAQ in . > > An idle thought: perhaps you can even use Plash's libc, or come up > with a slightly-modified libc that both Plash and you can use. Hi Paul, Thanks for this information. It looks interesting. I'll look at it in more detail when I get a chance (hopefully soon!). Are you involved in the Plash project, a user of it, or just have some knowledge of it? Cheers, Derrell --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-10.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-10.tmp" Date: Fri, 28 Apr 2006 13:14:42 -0700 From: Paul Eggert To: Derrell.Lipman@UnwiredUniverse.com Subject: Re: fopen() calls __open() Message-ID: <87d5f1wj7x.fsf@penguin.cs.ucla.edu> References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> <87lktqu3vy.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 Derrell.Lipman@UnwiredUniverse.com writes: > Are you involved in the Plash project, a user of it, or just have some > knowledge of it? The last one. --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-11.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-11.tmp" Date: Sat, 29 Apr 2006 19:30:05 +0100 From: Mike Hearn To: libc-alpha@sources.redhat.com Subject: Re: fopen() calls __open() Message-ID: References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> MIME-Version: 1.0 On Thu, 27 Apr 2006 13:55:06 -0400, Derrell.Lipman wrote: > If you have any other suggestions for me, I'd certainly like to hear them! The alsa AOSS program contains fopen wrapping code you can use. thanks -mike --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-12.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-12.tmp" Date: Sun, 30 Apr 2006 17:16:07 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: Mike Hearn Subject: Re: fopen() calls __open() Message-ID: References: <4450F946.6030909@redhat.com> <8xprx810.fsf@oberon-mail.internal> <445102AC.5090505@redhat.com> MIME-Version: 1.0 Mike Hearn writes: > On Thu, 27 Apr 2006 13:55:06 -0400, Derrell.Lipman wrote: >> If you have any other suggestions for me, I'd certainly like to hear them! > > The alsa AOSS program contains fopen wrapping code you can use. Thanks! I'll check it out. Derrell --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-13.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-13.tmp" Date: Sat, 29 Apr 2006 08:33:45 -0700 From: John Reiser To: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <44538759.4040103@BitWagon.com> MIME-Version: 1.0 Derrell.Lipman@UnwiredUniverse.com wrote: > If you have any other suggestions for me, I'd certainly like to hear them! For many particular cases, it is feasible to rewrite (patch) glibc at runtime. Disassemble to find the calls of interest, then change them. Of course this is architecture dependent, and some modes of SELinux aim to inhibit such modifications. But on x86, x86_64, and PowerPC it is not hard to do. -- --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-14.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-14.tmp" Date: Sun, 30 Apr 2006 17:17:01 -0400 From: Derrell.Lipman@UnwiredUniverse.com To: John Reiser Cc: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: References: <44538759.4040103@BitWagon.com> MIME-Version: 1.0 John Reiser writes: > Derrell.Lipman@UnwiredUniverse.com wrote: > >> If you have any other suggestions for me, I'd certainly like to hear them! > > For many particular cases, it is feasible to rewrite (patch) glibc > at runtime. Disassemble to find the calls of interest, then change them. > Of course this is architecture dependent, and some modes of SELinux aim to > inhibit such modifications. But on x86, x86_64, and PowerPC it is not > hard to do. This is an interesting option to consider. Can you point me to any open-source applications that actually do this? Thanks! Derrell --------------060501010506030305040606 Content-Type: text/plain; name="file:///home/ab/tmp/nsmail-15.tmp" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///home/ab/tmp/nsmail-15.tmp" Date: Sun, 30 Apr 2006 15:49:19 -0700 From: John Reiser To: Derrell.Lipman@UnwiredUniverse.com CC: libc-alpha@sourceware.org Subject: Re: fopen() calls __open() Message-ID: <44553EEF.30104@BitWagon.com> References: <44538759.4040103@BitWagon.com> MIME-Version: 1.0 Derrell.Lipman@UnwiredUniverse.com wrote: > John Reiser writes: >>For many particular cases, it is feasible to rewrite (patch) glibc >>at runtime. ... > This is an interesting option to consider. Can you point me to any > open-source applications that actually do this? The runtime loader itself (rtld, part of glibc) does patching when a module is marked with DT_TEXTREL in its ElfXX_Dyn. So look in the glibc source for TEXTREL. Of course one of the important ideas is that the relocation entries ElfXX_Rel specify exactly _where_ do to the patching, whereas your case might need a disassembler to find the locations. The objcopy module of the binutils project has disassemblers; there are others. Two other projects which use runtime patching are: http://bitwagon.com/rtldi/rtldi.html indirect runtime loader http://bitwagon.com/tub/tub.html address-space manager -- --------------060501010506030305040606--