Date: Mon, 30 Apr 2001 18:06:44 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Combining pcred and ucred Message-ID: <200105010106.SAA08105@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1010411235010.97720B-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1010411235010.97720B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 12, 12:03am, Robert Watson wrote: } Subject: Combining pcred and ucred } The observation may be made that although one possible rationale for the } division of ucred and pcred is that pcred might get modified while ucred } remains constant, reducing the number of copy-on-writes, in fact ucred is } almost always (if not always) modified when the pcred needs to be } modified. There is a small space savings associated with not caching the } real and saved uid/gid's all over the place, but this is negligible due to } the power-of-two memory allocation model, overhead of maintaining } additional refcounts, pointers, and uidinfo references, and the } copy-on-write nature of ucred. In fact, the pcred pointer substantially } complicates proc locking, and increases the cost of credential evaluation } and manipulation by introducing additional structures and dreferences. I } think there is a reasonable argument to be made that pcred should be } merged back into ucred, making ucred the sole source of credential } information for the process. In fact, I'd like to propose doing this, as } it allows the more extensive use of direct ucred to ucred comparison in } access control, rather than proces to process (hence the proc locking } issue). I've felt for a long time that pcred and ucred should be merged. I can't think of a good reason for them to have been separated in the first place. I suspect that they were each factored out of the old proc and user structures, though I would have expected to that only the effective uid would have migrated from the proc structure to the pcred structure so that it would be available if if the process and its user structure were swapped. I guess I'll have to dig through my library to satisfy my curiousity now. } There is one additional piece of information, that I know of, that should } probably move into ucred if pcred moves into ucred: this is the P_SUGID } flag, which is currently in the process flag field, bit might be more } formally considered a credential downgrade or credential modification } flag. Moving this flag into ucred would allow the flag to be available } for access control operations based on the ucred, which would also have } substantial structural benefits, albeit at the slight increase in cost } associated with ucred caching. I've suggested the same thing in the past. 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?200105010106.SAA08105>