On Thu, 8 Jan 1998 02:19:32 +0000 
 Ronald Khoo <ronald@demon.net> wrote:

 > Presumably it's for the same security/audit model reasons that
 > SecureWare C3 (e.g. SCO unix) implements the setluid() call.
 > It's supposed to be an audit identifier that *cannot* under any
 > circumstances be hidden.  The UID and EUID indicate whose
 > permissions are being used to authenticate whether or not something
 > may be done.  The login name indicates who actually initiated
 > the function, and should be preserved through inheritance
 > regardless of how many setuid-whoever programs or set*uid() calls
 > are made.

...not really... I mean, the login name can be changed with setlogin().

 > I'm guessing of course -- I'm no security weenie -- but there
 > seems little point in implementing a tiny part of an audit
 > infrastructure that we don't have, except for binary compatibility,
 > where we call always fill in the bsdos_ucred structure with the
 > constant string "root" :-)

Oh, it's easy to get that info, from the process's session... but the
point is that it's not really part of the process's _credentials_.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939