Something just came to me one day  -- yesterday, in fact -- and I
thought not to ask "why?" but to ask "why not?".  I've already
received some bets on the responses, so i figured, okay, the bets are
down,  let's go fishing.

I thought of a psetre{ug}id() mechanism.   The obvious question is,
of course, "why would we want to do that?", to which I must admittedly
respond, "I don't know".

In case nobody's clued in, it's a call to set the real/effective
user/group id of a process while it's running.

"But that's what set-id bits are for!"  I agree in the model we
currently have.

I just thought it more or less a cool hack; one person has suggested
a privilege broker of sorts to handle setting/resetting uids on the
fly as a possible application.

I can write the code (again -- it got clobbered by a sup last eve :-,).
But, before I do, I would really like to hear some feedback.  I think it
was partially inspired by fhopen() being mentioned -- which seems to me
like déjà vu, since I wanted an iopen() call about, oh, ten years ago
but the concept was shot down in the name of security.

I invite candid comments as long as they carry some intelligent weight
behind them; i.e., flames and knee-jerk reactions need not be submitted
for consideration.

Should this go to tech-kern?  [if so, cc: me since I don't think I'm
on that list as most of the stuff in the kernel is a bit atop my level.]


				--*greywolf;
--
Assumption #1:  Assuming that "God" exists, he/she/it is fallable.