Re: intercepting system calls?
Re: intercepting system calls?
- Subject: Re: intercepting system calls?
- From: Andrew White <email@hidden>
- Date: Tue, 24 Jan 2006 09:47:46 +1100
Erik Paulson wrote:
No, I'm looking for an unprivileged interface. PTRACE_SYSCALL means that
I can run two processes as user 'nobody' - the first one is the actual
process that I want to run on idle computers at the UofI, and the second
process, also running as 'nobody', can trace the first process, and
if need be do an RPC back to a server running at the UofW. I don't want
to run privileged code on the UofI machines.
Such an unprivileged interface doesn't appear to exist, short of some
sort of binary rewriting or single stepping.
One process really shouldn't be hacking the syscall API of a different process.
The clean way to do this in user space is to create a library shim that you
send your filesystem calls through. You can then attach to this shim and
redirect the appropriate FS calls or let them pass through to the
underlying system libraries (frameworks).
Yes, this means you need to recompile your applications. That's life if
you want user-space interaction.
If you can't recompile the application (because it's someone else's code)
then it's pretty dangerous to be trying to snarf calls at the framework /
kernel interface since there's no actual guarantee which calls are relevant
to you or that you have them all, nor is there any version control.
The other place to intercept is at a recognised extension API, such as the
filesystem API. As you noticed, this is typically a privileged operation.
--
Andrew White
--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.
_______________________________________________
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