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.

Mike Makonnen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to