From owner-freebsd-arch Fri Mar 16 11:11: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 4EB9E37B719 for ; Fri, 16 Mar 2001 11:11:01 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA81258 for ; Fri, 16 Mar 2001 14:10:56 -0500 (EST) Message-Id: <200103161910.OAA81258@cs.rpi.edu> To: freebsd-arch@freebsd.org Subject: idle wonderings about 'struct pcred' Date: Fri, 16 Mar 2001 14:10:55 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How would people feel about a fairly significant change to the pcred structure? The change would be to facilitate different types of authentication information about each process (say perhaps kerberos credentials, or private keys, or encryption keys for a file, ACL type info, etc. The possibilities are enormous). What got me thinking about this is how AFS handles this problem... it takes the first 2 GID slots away from the process to store kernel data into (yuck), there must be a better way, especially with the proliferation of authentication systems, and the need to store and manage that data easily and securely. NFSv4 will use GSS-API, for example, I think this system would be a much better approach than trying to store the authentication information in userland and needing to communicate that with the kernel somehow. What I had in mind would be something like the following: struct pcred { enum p_type; void *p_data; struct pcred *next; }; (That is a _very_ rough idea). Our current, traditional, 'struct pcred' would become 'pcred_unix', with a p_type of 0 (#define-d to PCRED_TYPE_UNIX) and would be stuffed into the p_data pointer). What do people think? -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message