Path: utzoo!attcan!uunet!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!IDA.ORG!wheeler
From: wheeler@IDA.ORG (David Wheeler)
Newsgroups: comp.os.minix
Subject: Re: message passing in minix
Message-ID: <1990Mar9.231723.20117@IDA.ORG>
Date: 9 Mar 90 23:17:23 GMT
Organization: IDA, Alexandria, VA
Lines: 50


mark@ccvr1.ncsu.edu (Mark Boyd):
> I'm trying to use messages for process syncronization.  I can
> find no way to use messages between user processes. Has anyone
> done this? I'm working on 68000 based systems ( ST and PT68k ),
> but I don't see where the problem would be any different on
> PCs. 
>                       Mark Boyd
>                       mark@ccvr1.ncsu.edu
 
I looked into this problem once.. I think it can be done
but haven't tried it myself.  I'm not aware of this capability being
in the latest version of MINIX, so you'd have to modify the OS.
I don't have the latest version of MINIX, so my info is based on
the original code.. see the MINIX code as published in "Operating Systems:
Design & Implementation", page 473.  Lines 1987-1988 and
1950-1953 mean that user processes may only execute a
sendreceive, and that user processes may only send to FS or MM.
 
A quick & dirty solution would be to remove these two sections, then
recompile MINIX.  There may be other sections which make this assumption,
but those two sections are certainly a minimum.
This would mean that user programs can send to anybody, including
internal OS processes.
You'll have to be very careful to send to the right places.
This modification makes MINIX totally unsecure!

A slightly better approach would be to make it so that
user programs can only call other user programs OR FS OR MM.
I doubt this is bulletproof (security-wise) either,  but it's
probably a good place to start.
For this, eliminate lines 1950-1953 and change lines 1987-1988 to:
if (caller >= LOW_USER &&
    (dest != FS_PROC_NR && dest != MM_PROC_NR && dest < LOW_USER))
    return(E_BAD_DEST);

One probablem is how to get the user process id in the first place:
in the short run I'd use a file with an agreed-on name to store
the process id.   Better yet would be a name server at a set
process id (as FS and MM are now).

A better approach would be replacing those sections with something
more sophisticated, so that certain user processes can talk with
certain other processes given certain secure conditions.
Other OS's do allow user processes to send & receive messages and
have some security checks (perhaps the process sets certain permissions
to allow certain other user tasks to send to it, etc, etc).

--- David A. Wheeler
    wheeler@ida.org