From owner-freebsd-arch Fri Jan 29 12:06:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04482 for freebsd-arch-outgoing; Fri, 29 Jan 1999 12:06:50 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04469 for ; Fri, 29 Jan 1999 12:06:44 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id VAA25958 for ; Fri, 29 Jan 1999 21:06:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA37755 for freebsd-arch@freebsd.org; Fri, 29 Jan 1999 21:06:36 +0100 (MET) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA23242 for ; Fri, 29 Jan 1999 10:38:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24944 for ; Fri, 29 Jan 1999 19:38:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA37398 for arch@FreeBSD.ORG; Fri, 29 Jan 1999 19:38:10 +0100 (MET) Date: Fri, 29 Jan 1999 19:38:09 +0100 From: Eivind Eklund To: arch@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <19990129193809.H34859@bitbox.follo.net> References: <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> <199901271944.LAA15317@kithrup.com> <19990129124932.A34859@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19990129124932.A34859@bitbox.follo.net>; from Eivind Eklund on Fri, Jan 29, 1999 at 12:49:33PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jan 29, 1999 at 12:49:33PM +0100, Eivind Eklund wrote: > I have been planning some changes for much of the same purpose. My > approach is to introduce a string identifying each context for suser(), > to allow people that want to hack on the authentication system an easy > place to start from. Eh - to expand somewhat (I forgot to include some significant parts): I was planning on adding both a string (hierarchical, to indicate placement in a tree), and a context-dependent extra void* parameter. This could e.g. be used to transfer the particular port a user is attempting to open. Note that this turn the strings passed to suser() into a type hierarchy (normal object-oriented inheritance) for the void* parameter. With the ANSI C requirement that any two structs that start with the same set of types (ie, have the same types of a number of members, starting from the first in the struct) should have the same memory layout, it should be possible to use standard C structures and just add members at the end (barring Bruce's mythical C compiler that tag types on structure pointers). To take the previous example with "fs/chflag/ufs/ffs" and "fs/chflag/ufs/lfs", we could have a struct authdata_fs_chflag_ufs { int somedata; char *otherdata; }; which has the data required for fs/chflag/ufs, and then struct authdata_fs_chflag_ufs_ffs { int somedata; char *otherdata; long ffs_specific_data; }; struct authdata_fs_chflag_ufs_lfs { int somedata; char *otherdata; struct mumbojumbo *lfs_specific_data; struct othermumbo *more_lfs_specific_data; }; with specific data for each of ffs and lfs, for this particular operation. Of course, the base setup (before we define all the data-formats etc) would be to just pass NULL. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message