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!

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

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/