Re: intercepting system calls?
Re: intercepting system calls?
- Subject: Re: intercepting system calls?
- From: Mike Smith <email@hidden>
- Date: Mon, 23 Jan 2006 14:01:20 -0800
On Jan 23, 2006, at 1:43 PM, Erik Paulson wrote:
A shared filesystem is great, if the administrators of both
computers
agree to use the same shared filesystems. That usually doesn't
happen
between institutions, for example.
This sounds like an administrative misconception revolving around
traditional use of network filesystems.
Hrm, without going way off-topic I don't think I can convince you
that my motivation is real
I don't think this is off-topic at all; the issue here is how to go
about doing
what you want to do, and how that relates to the way that Darwin works.
- my simple attempt at it is: If I want
to use idle computers at the University of Illinois and I'm at the
University of Wisconsin, I either have to get the UofI to mount my
file systems, or copy the files down to the UofI, or interpose and
make the processes running at the UofI believe that they're running
at the UofW.
That sounds a lot more ambitious than just files. Does "running at
the UoW"
mean "they see a filesystem at UoW", or does it include everything else
that they would see at UoW as well? Network interfaces? Context in
other parts of the system?
You're already talking about running privileged code on the client
system in order to intercept system calls;
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.
Ok; here's where we got a bit of a disconnect. The runtime environment
on Mac OS (which is primarily what Darwin lives to support) is a lot
more
complicated than that on something like Linux (unless you bring KDE
into the picture, and even then...).
It's not sufficient in the general sense to redirect a single
application; there
are quite a large number of situations in which work is done for an
application
by proxy, and to have that happen correctly the proxy has to have
relevant
context.
Now, arguably you can redirect the proxy requests, but now you're
talking
about handling distributed shared memory as well, and don't forget the
heavy use of Mach-style messaging.
A general mechanism needs to take all these things into account. One
built
on top of intercepting just BSD system calls is going to be a partial
solution
at best, and as such better left undone.
Such an unprivileged interface doesn't appear to exist, short of some
sort of binary rewriting or single stepping.
You can achieve this with the dynamic linker interfaces already
mentioned.
= Mike
_______________________________________________
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