From owner-freebsd-bugs  Tue Jan 18 13:30: 5 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8A48A1532F
	for <freebsd-bugs@FreeBSD.org>; Tue, 18 Jan 2000 13:30:02 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id NAA26623;
	Tue, 18 Jan 2000 13:30:02 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 4C7E714BE5; Tue, 18 Jan 2000 13:27:57 -0800 (PST)
Message-Id: <20000118212757.4C7E714BE5@hub.freebsd.org>
Date: Tue, 18 Jan 2000 13:27:57 -0800 (PST)
From: paco@cs.virginia.edu
To: freebsd-gnats-submit@FreeBSD.org
X-Send-Pr-Version: www-1.0
Subject: kern/16195: 16-bit uid/gid struct in sys/ipc.h
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         16195
>Category:       kern
>Synopsis:       16-bit uid/gid struct in sys/ipc.h
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 18 13:30:02 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     Paco Hope
>Release:        3.3-RELEASE
>Organization:
University of Virginia
>Environment:
FreeBSD lava003.cs.virginia.edu 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Tue Jan 18 12:05:39 GMT 2000     root@lava003.cs.virginia.edu:/usr/src/sys/compile/LAVA  i386
>Description:
/usr/include/sys/ipc.h (and /usr/src/sys/sys/ipc.h) provides a data
structure "struct ipc_perm" which does not store UID and GID information
properly.  It currently looks like this:
struct ipc_perm {
        ushort  cuid;   /* creator user id */
        ushort  cgid;   /* creator group id */
        ushort  uid;    /* user id */
        ushort  gid;    /* group id */
        ushort  mode;   /* r/w permission */
        ushort  seq;    /* sequence # (to generate unique msg/sem/shm id) */
        key_t   key;    /* user specified msg/sem/shm key */
};

It needs to treat UIDs and GIDs in the proper way.  I'm using NIS
(Solaris NIS, not NIS+, server) to get my password entries, but I
don't think this matters.
>How-To-Repeat:
Create a user with a large UID (> 65536).  I was using a user whose
UID was 70883.  Create a shared memory segment with something like:
shmid = shmget(IPC_PRIVATE, MY_SHM_SZ, 
                 SHM_R|SHM_W|(SHM_R>>3)|(SHM_W>>3)|IPC_CREAT);

Then, try to attach to it with something like:
p = shmat(shmid, 0, 0)

It will fail.  ipcs will also show the wrong UID as the owner. E.g.
Shared Memory:
T     ID     KEY        MODE       OWNER    GROUP
m 196609          0 --rw-rw----     5347 csfaculty

That's a memory segment created by UID 70883.  Only root will be
able to delete such segments, since the UIDs won't match when
a user tries to run ipcrm.
>Fix:

Four steps to a fix:
1.  Change ipc.h to update the struct ipc_perm as shown below.
2.  Recompile the kernel.
3.  Recompile libc.
4.  Recompile any programs that use shm calls (e.g. ipcs, ipcrm, X stuff)

struct ipc_perm {
        uid_t   cuid;   /* creator user id */
        gid_t   cgid;   /* creator group id */
        uid_t   uid;    /* user id */
        gid_t   gid;    /* group id */
        ushort  mode;   /* r/w permission */
        ushort  seq;    /* sequence # (to generate unique msg/sem/shm id) */
        key_t   key;    /* user specified msg/sem/shm key */
};

I'm not the savviest of kernel hackers here, but the trivial
programs which exhibited bad behavior appeared to work correctly
after the above four steps were performed.

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message