I had written:
> Oh yes, there's a 3rd choice - believe the UID that's
> stuffed into the kernel. Since this can only be set by
> certain administrative programs (ie, login), this should
> normally be whatever value is in the password file, which
> is perfectly adequate security if what you're trying to secure
> is data that's stored on the local machine. If you are
> instead trying to secure a network resource, you may want
> to think through your security model very carefully.
Nathan Neulinger <[EMAIL PROTECTED]> replied:
> I don't believe this is the case... As near as I can tell, anyone can issue
> the GetToken and SetToken calls.
>
> In fact, for a while, I had a couple of little programs sitting around
> that would take your current tokens and convert to a easily transportable
> ASCII string, and another one that would take the string and set your
> current token from it. Neither required any special privileges.
Yes, you are right, but that's not quite what I meant. I didn't
mean the vice ID associated with the token, which is indeed
easily spoofed. I meant the process UID set by setuid/setreuid & etc.,
which is part of the standard Unix security model. I should have said
that more clearly.
-Marcus Watts
UM ITD PD&D Umich Systems Group
