Date: Sat, 17 Mar 2001 12:20:38 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' Message-ID: <Pine.NEB.3.96L.1010317121828.13810C-100000@fledge.watson.org> In-Reply-To: <200103161910.OAA81258@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I think you're describing the direction that ucred is already moving in.
Take a look at struct ucred in -CURRENT, where things like the jail
pointer are now there instead of directly under struct proc. If you look
at the various POSIX.1e capability and MAC patches, you'll see that they
introduce new stuff in ucred. I actually submitted patches years ago to
add a extension field to proc, but the place to put it is really ucred.
However, you run into conflicts concerning owners of the extension field
-- I also have fairly extensive patches underway that make ucred run-time
extensible more generally, but they're at least 8 - 12 months away from
being ready to integrate because we need to do substantial performance
analysis, need better support for run-time extension and ownership, etc.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
On Fri, 16 Mar 2001, David E. Cross wrote:
> 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
>
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?Pine.NEB.3.96L.1010317121828.13810C-100000>