Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Oct 2002 22:18:10 +0300
From:      Maxim Sobolev <sobomax@FreeBSD.ORG>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" <vova@express.ru>, freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: short uid/gid
Message-ID:  <20021014191810.GA338@vega.vega.com>
In-Reply-To: <Pine.NEB.3.96L.1021014132336.56465H-100000@fledge.watson.org>
References:  <E180zjq-000OrL-00@vbook.express.ru> <Pine.NEB.3.96L.1021014132336.56465H-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Linux solved the problem by introducing a new flag for {msg,shm,sem}ctl(3)
interfaces (IPC_64), which if set tells the kernel that user supplies
new version of the structure. The kernel itself internally keeps all
relevant information already in IPC_64 format, doing conversion before
returning it to user if IPC_64 isn't set. I think that for portability
reasons we should at least consider the same or similar route.

-Maxim


On Mon, Oct 14, 2002 at 01:27:57PM -0400, Robert Watson wrote:
> Yeah, this is a Known Problem, and it's quite unfortunate, actually.  I
> looked at trying to solve it -- changing the types respectively to uid_t,
> gid_t, and mode_t, but it involved a lot of ABI munging because the
> structures are shared between the userland interface and the kernel
> implementation.  The result is that any change in the kernel structure
> really requires you to break out the user structures from the kernel
> structure, which requires a lot of work.  Also, ipc_perm is shared between
> all three SysVIPC services, and to compound things, there are already
> ofoo() interfaces for older versions of the structures.  My belief is that
> seperating the user and kernel structures is really necessary -- making a
> kipc_perm, etc, so we can better support fine-grained locking and
> extensible security.  However, someone has to do the grunt work, and last
> time I tried, I spent several days and only made a bit of progress.  If
> you want to give a first pass at breaking out the user and kernel
> structures and send a patch, I'll be happy to work with you to get it
> integrated.  I think the steps are:
> 
> (1) Divorce user and kernel structures for all of the SysVIPC interfaces,
>     and provide functions to map between them as necessary.
> 
> (2) Remove the original compatibility interfaces left over from eons ago
>     (and figure out how many eons ago so we know what ABIs we're finally
>     removing).
> 
> (3) Define new userland versions of necessary structures and create a new
>     set of ofoo() and foo() interfaces based on the change.
> 
> (4) Go back through and dribble the kernel structures with new toys, such
>     as 'struct label', etc.
> 
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org      Network Associates Laboratories
> 
> On Mon, 14 Oct 2002, Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info wrote:
> 
> > 
> > Hi
> > 
> > I have found that SysVIPC functions uses structure with short uid/gid types.
> > 
> > What is valid solution ?
> > 
> > Change types to uid_t/gid_t (but this will broke binary compatibility)
> > Change syscalls to old_* and add new with "right" structures,
> > or something else ?
> > 
> > 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 */
> > };
> > 
> > --
> > Vladimir B. Grebenschikov
> > vova@sw.ru, SWsoft, Inc.
> > 
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-arch" in the body of the message
> > 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021014191810.GA338>