Date: Fri, 29 Jan 1999 19:38:09 +0100 From: Eivind Eklund <eivind@FreeBSD.ORG> To: arch@FreeBSD.ORG Subject: Re: "JAIL" code headed for -current. Message-ID: <19990129193809.H34859@bitbox.follo.net> In-Reply-To: <19990129124932.A34859@bitbox.follo.net>; from Eivind Eklund on Fri, Jan 29, 1999 at 12:49:33PM %2B0100 References: <29763.917434096.kithrup.freebsd.current@critter.freebsd.dk> <199901271944.LAA15317@kithrup.com> <19990129124932.A34859@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990129193809.H34859>