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-current" 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>