Re: Interposing library calls
Re: Interposing library calls
- Subject: Re: Interposing library calls
- From: "Jernej Azarija" <email@hidden>
- Date: Tue, 29 Jul 2008 10:13:38 +0200
Thanks for all the help.
I have another question before I stop annoying you.
Suppose such library is created - is there any way it could be
exported globally so that it affects every single binary on the
system? As far as I can see, exporting DYLD_INSERT_LIBRARIES (through
/etc/bashrc or whatever) doesn't affect applications running through
the GUI which seems reasonable but makes me wonder how to preload the
library in this cases.
Jernej.
On Fri, Jul 25, 2008 at 9:21 PM, Terry Lambert <email@hidden> wrote:
>
> On Jul 25, 2008, at 5:17 AM, Jernej Azarija wrote:
>>
>> Hello,
>>
>> this is a continuation of the previous thread located in darwin-kernel
>> at : http://lists.apple.com/archives/Darwin-kernel/2008/Jul/msg00015.html
>> .
>>
>> I assume my question is more on topic here.
>>
>> The conclusion reached in the above mentioned thread is that it's
>> preferred to interpose library calls (in this case open/close) from a
>> library loaded at runtime. I've therefore created a small example
>> trying to intercept open, resolve the given path (using realpath()),
>> print the resolved path and pass the work to open().
>
> For these things to work, you need a relatively deep understanding of the ABI and linkage model.
>
> Quinn is correct that library interpostion is not officially supported by Apple. In general, this is because you will have to lock-step update your library with system library updates from Apple. The specific example I had in mind when I read Mike's suggestion on interposition is probably the same one Mike had in mind. Mine was "mallocdebug" (Mike used to maintain it, so that's why I'm guessing it's his example).
>
> It's possible to interpose, but you have to understand the lock-step nature of interposition, along with the nature of the library implementation, and the use of multi-level namespaces within libraries. The best source example is "mallocdebug", but again, you should be cautioned that what you want to do will have to be lock-stepped.
>
> Objective-C based code was intended to support runtime overrides as a language feature; you can still run into problems with library compatibility there, but it's less frequent when you follow the rules.
>
> [ ...]
>
>> I'm clueless about what is causing this issue. As far as I've checked
>> libc' implementation, getcwd() is not using open() (at last not
>> directly). I'd be glad to hear a hint on how to overcome this issue.
>
> __getcwd() uses open to get ".", then asks the system for the path to ".". Depending on the answer it gets, it may go and ask for ".." recursively until it gets all path components to the root of the volume. You appear to be interposing open at the wrong level in the symbol namespace, so getcwd() is calling your open() rather than the system open().
>
> The difficulty in getting this type of detail right is another reason it's not supported. You are also unlikely to get it right to the point that multiple libraries can interpose the same set of calls, so if someone else tries to do what you are trying to do at the same time, one of you is going to be unhappy.
>
>
>> Ps. I'm aware that this method is not officially "supported" by Apple,
>> neither is any kernel "hacking" of this type. All this makes me
>> wonder, how is someone able to deploy applications if it can't use
>> internal information - in my opinion, forcing people not to mess with
>> this stuff is just encouraging bad design of applications.
>
> The general cause of problems like the ones you are running into is usually that you are asking about how to implement a solution to a problem, when you've already arrived at the solution. Typically, it's better to ask "how do I solve this problem?" rather than "how do I implement this solution which I've already arrived at?", since you'll likely get more useful answers.
>
> -- Terry
--
http://nd47.coderock.org/~azi
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden