Date: Fri, 16 Mar 2001 14:10:55 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: freebsd-arch@freebsd.org Subject: idle wonderings about 'struct pcred' Message-ID: <200103161910.OAA81258@cs.rpi.edu>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103161910.OAA81258>