Tech Insider					     Technology and Trends


		   Linux Activists Mailing List Archives

Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!gatech!
usenet.ins.cwru.edu!ncoast!davewt
From: dav...@NCoast.ORG (David Wright)
Subject: Problem w/SYSV IPC calls in SLS 1.02
Organization: North Coast Public Access *NIX, Cleveland, OH
Date: Sun, 25 Jul 1993 08:36:45 GMT
Message-ID: <CApp9A.D9y@NCoast.ORG>
Summary:  I can't get it to work...
Lines: 50


	I have been trying to get the SYSV IPC calls to work, but with no
luck (well, only partial luck). I have been working on my big multi-player
game, as I have said before, but when I got to the portion where the actual
communication between the clients and the servers take place, I think I found
a bug either in the kernal that comes with SLS 1.02, or in the IPC code that
comes with SLS 1.02.

	I have tried to compile two simple programs, one that creates a port
and sends messages to the other task, and another program that just sits and
listens for messages and repsonds to them. The programs came right out of a
SYSV IPC programming book, and go along with what I have used myself in the
past and had work.

	Basically, to create the port program A dos:
		"msgid=msgget(KEY, IPC_CREAT|0666)"
This call succeeds (verified in gdb), and program A goes on to wait for
me to type something before sending a test message.
	Program B does this to find the port:
		"msgid=msgget(KEY, 0)"
This call is FAILING with a "permission denied" message (when printed with
"perror"). When I saw that I tried running both programs as ROOT, and it
actually worked. Howver, this is not a valid way for the SYSV IPC's to
work.

	After doing that I tried running program A in gdb again, and looked
at the *.msg_perm.mode field, and right after the msgget() to create the
message port the mode was "438", *not* 666 as it should have been.

	I then tried to put in a msgctl() call to CHANGE the mode (which it
should have let me do, as I was the message port owner, also verified in
the structure), and that failed with a "Permission denied" error as well.

	I am using the kernal source files that came with SLS 1.02, which
is listed as "0.99.pl9-3" by "uname". The IPC header files were NOT
installed, and there was no "libipc.a" file is /lib or /usr/lib, so I had
to use the two patch files in the /usr/src/ipc directory to add the IPC
capabilities to the kernel and then create /usr/lib/libipc.a using the docs
in the /usr/src/ipc.

	Did I do something wrong when I added IPC to the kernel, or is this a
known bug with the current IPC implementation?

						Dave

	
-- 
	David Wright		dav...@NCoast.ORG
	"The first UseNet Newton Fanatic"
        "PDA's are NOT 'Pen Computers'!"

Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!wupost!csus.edu!
netcom.com!gil
From: g...@netcom.com (Gilbert Nardo)
Subject: Re: Problem w/SYSV IPC calls in SLS 1.02
Message-ID: <gilCAqLx4.CGq@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.1 PL8]
References: <CApp9A.D9y@NCoast.ORG>
Date: Sun, 25 Jul 1993 20:22:15 GMT
Lines: 67

David Wright (dav...@NCoast.ORG) wrote:
[excerpted]
: 	Basically, to create the port program A dos:
: 		"msgid=msgget(KEY, IPC_CREAT|0666)"
: This call succeeds (verified in gdb), and program A goes on to wait for
: me to type something before sending a test message.
: 	Program B does this to find the port:
: 		"msgid=msgget(KEY, 0)"
: This call is FAILING with a "permission denied" message (when printed with
: "perror"). When I saw that I tried running both programs as ROOT, and it
: actually worked. Howver, this is not a valid way for the SYSV IPC's to
: work.

	I believe the error is in the IPC kernel source file msg.c (see
test patch towards end of post).  According to [Stevens,p124], passing
a perm flag of 0 should allow access to an IPC channel if it was
created with world access flags enabled.
	In msg.c, the sys_msgget() function calls ipcperms() with, in
your case, flag of 0. This causes ipcperms() to return a failure value
because of the first test in the following lines of util.c:

        if (!(flag & perm) || flag & perm & ~ipcp->mode)
                return -1;

	The patch below does not change the util.c file because other
parts of the IPC code use it (and I am not fully familiar with them).
Instead, the patch modifies the msg.c file to take care of the special
case.  ***CONTACT** Krishna Balasubramanian (bala...@cis.ohio-state.edu)
to see if this patch is appropriate and is all that is needed (I suspect
that others may be needed).

[Stevens]	Unix Network Programming, W. Richard Stevens,
		ISBN 0-13-949876-1

======================patch begin========================
*** msg.old.c   Sun Jul 25 12:35:19 1993
--- msg.c       Sun Jul 25 12:34:42 1993
***************
*** 275,283 ****
                return -EEXIST;
        msq = msgque[id];
        if (msq == IPC_UNUSED || msq == IPC_NOID)
                return -EIDRM;
!       if (ipcperms(&msq->msg_perm, msgflg))
                return -EACCES;
        return msq->msg_perm.seq * MSGMNI +id;
  } 
  
--- 275,287 ----
                return -EEXIST;
        msq = msgque[id];
        if (msq == IPC_UNUSED || msq == IPC_NOID)
                return -EIDRM;
!       if ( !msgflg ) {
!               if ( ipcperms(&msq->msg_perm, 0007) )
!                       return -EACCES; /* world access not in msg_perm */
!       }
!       else if (ipcperms(&msq->msg_perm, msgflg))
                return -EACCES;
        return msq->msg_perm.seq * MSGMNI +id;
  } 
======================patch end========================
-- 
Gil Nardo                  | g...@netcom.com
Migrant Computing Services | (415)664-1032 (voice)
1032 Irving Street, #435   |-----------------
San Francisco, 94122       | Save the Universe: Stop Entropy Now!

			      USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/