Date: Sun, 18 Mar 2001 19:06:25 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: Robert Watson <rwatson@freebsd.org> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-arch@freebsd.org, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' Message-ID: <200103190006.TAA44321@cs.rpi.edu> In-Reply-To: Message from Robert Watson <rwatson@freebsd.org> of "Sat, 17 Mar 2001 12:20:38 EST." <Pine.NEB.3.96L.1010317121828.13810C-100000@fledge.watson.org>
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. Actually, that most recent change is exactly the opposite direction that I am looking to go, that was a direct change to ucred itself, so any of the userland programs that link against libkvm need to be recompiled, etc because the size of the structure changed. Also that increases the size of the proc structure for everyone (even those of us not using jail). If we extend this and have every auth chuck its own data directly into the proc like this the structure and book-keeping are going to grow to be huge, and most us us are only ever going to use one or 2 of them anyway. (Yes, I know the ucred and pcred are only links into the proc structure, so the proc structure itself doesn't change size, but if there is some program out there (lsof perhaps?) that looks at the data, it will get confused; and it is more data the kernel has to move around, even if it is totally unused) What I want to see happen is the cred strucutures become meta-structures. They have no data in themselves, but they point to data. Thus I can add a new authentication/authorization method as a module without recompiling the kernel (indeed if this is inhouse, proprietary code, I can release binaries only and not need to sync up my credential information with the rest of the world). Also each process only has the information associated with it that it really needs. If you form a jail(8) (I admit I am going out quite on a limb here, since I don't know how the jail code works ;) then a "CRED_JAIL" struct gets added to the table for that process and only the processes within the jail have it. Now, someone in the jail decides to use CIFS, that cred is added on, etc. It grows (and shrinks) as needed. There is additional overhead in having the additional pointers/indirection. I think this is "ok" for a number of reasons. First, 99.9999% of everything will be based on "CRED_UNIX", which one can guarantee will be the first entry in the list: all credential information is inherited from the parent (via fork, and modified later with sycalls such as set??id()/exec()), the parent of everything is init, which will only have CRED_UNIX available to it (as setup by the kernel). So, the majority of requests will just need to go through one lookup and not need to iterate through the entire list. With appropriate data sharing (this gets very tricky for some forms of authentication, which is why I think a cred_flags field may be desired to control how some entries handle things like exec() and fork()) there will not be any additional data copies unless explicitly asked for via a syscall to change the credentials (this is done now even from what I can tell). Finally, I can see some of the routines using a caching mechanism if they need additional performance, or impliment the entire thing as a hash, but I don't think that will be a problem given the very few authentications that one will use at any single time and the relative infrequency that they are actually checked. Finally, and in summary :) I think this is a good idea and the way-to-go just for the ideals of modularization and data-hiding. -- 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?200103190006.TAA44321>