On Tue, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin <[EMAIL PROTECTED]> wrote:
> > This solution has the advantage that the only code that has to change is > > the ucred and setuid/gid helper functions that already know about the > > struct uidinfo functions. In fact only three functions not related to > > uidinfo(9) need to be touched: proc0_init(), change_ruid(), > > change_uid(). The disadvantage is the memory bloat and a small amount of > > code complexity (but as I said, this is localized, and not very complex > > either). > > > > Do you like it? > > Should I go ahead and implement a patch? > > Anything I overlooked? > > It won't work if you have to change a uidinfo more than once. I still prefer > just doing the uifind() at the beginning of the function, passing in the > uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's > in case of failure. Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. With that assumption in mind I wanted to compartmentalize the allocation of struct uidinfo. It seemed cleaner to me to have only uifind() and its immediate callers have intimate knowledge struct uidinfo creation and destruction, but I suppose if setuid() (for example) knows enough to compare cr_ruid et al, its knowledge of one more member isn't that bad. Basically, I wanted to avoid having to touch every function that changes the r/e uid, and touch just those that already dealt with the uidinfo. In any case, I'll submit a patch to you doing it the way you suggested. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
