Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!apple!altos!altos86!alex From: alex@altos86.Altos.COM (Alex Win) Newsgroups: comp.unix.sysv386 Subject: Re: SCO OpenDeskTop v1.0/Secureware HACK! Message-ID: <4381@altos86.Altos.COM> Date: 15 Nov 90 17:36:42 GMT References: Reply-To: alex@altos86.UUCP (Alex Win) Organization: Altos Computer Systems, San Jose, CA Lines: 57 In article mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >... >I can only log on as >root on tty01, and the system says "Security database corrupt. >However, root login on tty01 is allowed." If I try to log on as a >normal user or on a different terminal, it says "Can't rewrite >Terminal Control Database entry. See Authentiation Administator." It appears that you may either have a lock file lying around or your "Terminal Control Database" file is corrupt. Go into single-user mode and see if "ttys-t" or "ttys-o" is present in /etc/auth/system. If so, remove it -- the file prevents users from updating the Terminal Control Database when logging in. If the lock files are not there, your Terminal Control Database may be corrupted. Move your /etc/auth/system/ttys file to a temp file, create an empty ttys file in /etc/auth/system, and run '/tcb/bin/ttys_update'. This will recreate your Terminal Control Database from your init.base file in your /etc/conf/cf.d directory. >(Incidentally, /bin/login seems to have the name "root" hardcoded into >it -- I have a csh root called "coot", and I can't log in as coot on >the console. UID 0, GID 0, home directory /. You're right. If login fails on non-console ports, your last ditch option is to login on /dev/tty01 (or /dev/console) as 'root'. You'll probably encounter problems with setuid commands (like /tcb/bin/integrity) since the login did not go through normal means. I would think single-user login might give you better luck. >Thing get >curiouser and curiouser.../tcb/bin/authck -av lists problems with >several users, including "coot" and my own login, "mju". It claims to >fix them. However, the next time I run authck, it uncovers the same >problems, and again offers to fix them. I've never seen 'authck' work. >... >How about how to contact Secureware, to maybe get some docs? SCO says >that they're "proprietary"; they can't even tell me the format of a >/tcb/files/auth/x/xxx file. Security by obscurity, folks, isn't >security at all. > From the look of it, I don't believe the problem is with the /tcb/files/auth/... files. But if you need to know, read the Security chapter in the System Administrator's Guide and you can pretty much correlate it to the fields in the xxx files. If not, having the source to the SecureWare library helps :-) -- Alex Win (alex@Altos.COM) Altos Computer Systems 2641 Orchard Pkwy, San Jose, CA 95134