From owner-freebsd-current Tue Oct 15 19:45:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B0937B401; Tue, 15 Oct 2002 19:45:07 -0700 (PDT) Received: from clmboh1-smtp5.columbus.rr.com (clmboh1-smtp5.columbus.rr.com [65.24.0.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80CE743E77; Tue, 15 Oct 2002 19:45:06 -0700 (PDT) (envelope-from dzerkel@columbus.rr.com) Received: from zoomer (dhcp065-024-067-163.columbus.rr.com [65.24.67.163]) by clmboh1-smtp5.columbus.rr.com (8.11.2/8.11.2) with ESMTP id g9G2j4023824; Tue, 15 Oct 2002 22:45:04 -0400 (EDT) Content-Type: text/plain; charset="koi8-r" From: "Danny J. Zerkel" Organization: Zerkular Systems To: Maxim Sobolev , Robert Watson Subject: Re: short uid/gid Date: Tue, 15 Oct 2002 22:47:38 -0400 User-Agent: KMail/1.4.3 Cc: "Vladimir B. Grebenschikov,Moscow,408-7227,123-4567,Some-info" , freebsd-arch@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20021014191810.GA338@vega.vega.com> In-Reply-To: <20021014191810.GA338@vega.vega.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200210152247.38939.dzerkel@columbus.rr.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At least for our Linux emulation layer, supporting IPC_64 would be one of the pieces (probably the main one) keeping The Sims from running. The other thing we are missing is the Linux ioctl() interface for reading MSDOSFS directories, but that may be optional. I will eventually take a look at this (IPC_64) if the scheduling fairy brings me the time. Danny dzerkel@columbus.rr.com On Monday 14 October 2002 15:18, Maxim Sobolev wrote: > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message