Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!caen!ox.com!mudos!mju
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Newsgroups: comp.unix.sysv386
Subject: SCO OpenDeskTop v1.0/Secureware HACK!
Summary: Can someone please help me?  I'm at the end of my rope...
Message-ID: <sewJs2w163w@mudos.ann-arbor.mi.us>
Date: 13 Nov 90 02:24:03 GMT
Organization: The Programmers' Pit Stop, +1 313 665 2832
Lines: 52

Okay, folks, I've had it up to *here* with SCO's broken "security"
system.  I think we all know that it's poorly integrated with the OS,
that it's an absolute pain in the ass, and that the first thing SCO
should do in 3.2v3 is make the stupid thing totally, completely
removable.

However, that's not what my problem is.  My problem is this: The
system is broken, and I can't figure out how to fix it.  When I boot
up multi-user, cron(8) aborts with "cron: can't find group cron".  If
I try to su(1) from a non-root account, it tells me that
create_file_securely() exited with status 2.  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."
(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 /.  I guess this is another
incompatibility -- superuser privileges are UID and GID 0, not having
the login-id "root".  It's a good thing I didn't rename "root"
something like "god", or I'd *really* be in trouble.)  When I log in
as root in single-user mode, it appears that
/etc/auth/system/gr_id_map isn't getting created like it should be.

To add insult to injury, /tcb/bin/integrity says "Not authorized to
run /tcb/bin/integrity" when I'm logged in as root.  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.

This all seems to have started when I tried to add a new group by
editing /etc/group directly, instead of going through sysadmsh.
However, I've removed that group (and all users that were in it), and
things are still broken.  I've talked to SCO technical support, and
they're completely stumped.  (I have an appointment to talk to a
"senior technical analyst" tomorrow, but I'm not exactly in the most
optimistic of moods about it.)  Quite frankly, I'm getting sick and
tired of ODT's stupid security system, and if I didn't have to support
my customers who are running ODT, I'd trash it and get REAL SysVr3.2.
Does anybody have any idea about what's *really* happening, and
possibly how to fix it?

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.

--
Marc Unangst               |
mju@mudos.ann-arbor.mi.us  | "Bus error: passengers dumped"
...!umich!leebai!mudos!mju |