From owner-freebsd-hackers Tue Jan 23 00:21:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA14362 for hackers-outgoing; Tue, 23 Jan 1996 00:21:33 -0800 (PST) Received: from ccslinux.dlsu.edu.ph (linux1.dlsu.edu.ph [165.220.8.15]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA14356 for ; Tue, 23 Jan 1996 00:21:23 -0800 (PST) Received: (from pcua@localhost) by ccslinux.dlsu.edu.ph (8.6.11/8.6.9) id QAA12073; Tue, 23 Jan 1996 16:22:56 +0800 Date: Tue, 23 Jan 1996 16:22:56 +0800 (GMT+0800) From: John Patrick Cua To: Gordon Burditt cc: hackers@freebsd.org Subject: Re: exec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Thanks for your reply. On Mon, 22 Jan 1996, Gordon Burditt wrote: > >i have a problem regarding a program that i am testing out. > > > >how do i replace the code of a stopped(by SIGSTOP) process externally so > >that once i signal it to continue it will be executing my replaced code? > > Sounds like an enormous security hole to me. Why not just KILL > the process in question and execve the replacement code yourself? It seems but the privilege may be given in such a way only to the superuser or the process with the same euid just like signals. > > Why not install a signal hander in the target process which does > the execve you'd want? Of course, you need to compile this in first. > > Besides building a virus, what is the purpose of doing this? I am developing a Process Migration facility in UNIX. This type of facility is used by load distribution algorithms or daemons to transfer a process in the middle of its execution to another computer in the network. The goal of the facility is transparency for the user and no add-ons to the kernel which means the user does not have to add any additional code in his program for it to be migratable. Just how is it designed to work? First, the running target process is stopped (SIGSTOP), the process address space and structure will be transferred to another computer and restarted there. To preserve interprocess communication through signals, the stopped process is to be replaced with a dummy process. The dummy process is actually a signal handler to catch and send signals(except SIGKILL and SIGSTOP) to the migrated process. The links of other processes to the migrated process must remain through the dummy process. A - my process B - target process C - dummy process In other words, A will replace B with C. When processes are signalling B it is actually C signalling to B in a remote computer through RPC. My question is... does anybody have a possible solution for this problem? Patrick Cua De La Salle University