Bad login user id(sco-unix)

[pri=20 Chris Halpin]

>From article <18633 at rpp386.cactus.org>, by jfh at rpp386.cactus.org (John F. Haugh II):
> In article <1826 at overlf.UUCP> emanuele at overlf.UUCP (Mark A. Emanuele) writes:
>>In article <24816 at adm.BRL.MIL>, hliao at opus.calstatela.edu writes:
>>> 	Why don't you try "exec login"?
>>
>>That won't work because of the security "features" included with SCO.
> 
> there is an alleged attempt to port my login suite to SCO UNIX.  if
> you want to join in on the fun, why don't you try to pick up a copy
> of the sources from an archive site near you.  or just wait until
> the appropriate bodies send their changes back to me to post ...
> 
> i don't know what all SCO did to UNIX to make it so ornery, so i
> can't comment on how bizarre the security features in SCO UNIX are.
> 
> just remember boys and girls - security is your FRIEND!

SCO UNIX uses Secureware's SMP product. It's a SYSV add-on (not yet
certified) that provides a C2 level of trust.  login(1) was extensively 
modified to accomodate the requirements of C2. The most notable is
addition is the concept of the luid (login uid) (other hacks include
a user defined timeout period and the inclusion of a separate password like
configuation file  [one per user] that controls the users privs). 
The luid is an additional uid associated w/every process that is set at 
login time and CAN NEVER be changed (changes to the kernel include a new 
system call - setluid()). It is used by the audit trail to allow tracking of 
changes in identity.  The only way to change your luid under SCO UNIX/Securware
is to logout and login again. exec(2)ing login will result in an attempt
to setluid(2) that fails since the luid is already set.  The luid also
creates problems with cron (you need to shutdown to restart cron since it
needs to be run w/no luid set so that is may run its jobs as any user it 
chooses).