SCO doesn't sell UNIX

[Rob Healey]

In article <1990Dec3.050103.21819 at ping.uucp> gorpong at ping.uucp (Gordon C. Galligher) writes:
>In article <1990Nov29.205938.3671 at digibd.com> rhealey at digibd.com (Rob Healey) writes:
>Have you used the crontab of SCO's unix?  Have you used the 'df' program of
>SCO's unix?  Have you used the su of SCO's unix?  All of these things are
>not 'standard' UNIX, even with C2 security relaxed.  You cannot 'su' to 
>root (or anyone else) unless you mess with the tcb/auth/crap files manually.
>If you finally are successful in su'ing to root, you are really NOT root.
>You cannot do things like change user's passwords (unless your LOGIN-ID has
>a special thing set up on tcb/auth/crap, and then you can be the normal user
>and STILL change other's passwords).  If you 'su' to another user, you cannot
>use 'crontab' which breaks things like:  su uucp -c 'crontab /tmp/crontab'.
>This is all things which are done in a user's point of view (yes, users DO
>use the 'su' command, well, er, they DID before SCO "unix" came out...).
>
	1) The output of df and df -t on my SCO UNIX 3.2v2.0 EXACTLY
	   matches the format of the df and df -t commands on an
	   AT&T WGS running 3.2 5 feet away. These are the only two
	   options I use. Also, the output of df /usr/lib matched
	   as well. So, I don't see what the problem is.

	2) Crontab and su do differ due to security. I'm not sure
	   I'd want su uucp -c 'crontab /tmp/crontab' to work but
	   I usually like to mess with crontabs directly. su to
	   root can be granted via sysadmsh but I use a different
	   program anyhoo and execsuid is all an authorized user needs.
	   We don't have users using su to get things done, we do
	   it a different way but that's a matter of administration...

	3) As far as passwd goes, take away auth privledge with sysadmsh
	   or edit /etc/auth/system/default and /etc/auth/subsystem/auth
	   manually. The user can still change thier own password but
	   not everyone else's. It does work, I tried it just now.
	   The admin's like the fact that they don't have to su in
	   order to change a password that someone forgot. By the way,
	   by setting up /etc/default/{goodpw,passwd} properly you
	   CAN make passwords as strict or as loose as you want.
	   sysadmsh can be used to turn off password ageing as well
	   for all users or just select users.

>You may say that this is the security thing; well, yes it is.  The problem
>is, SCO has made the security TOO much a part of the entire operating
>system.  Merely 'relax'ing security in the sysadmsh is not enough.  Too
>many programs expect it to be running.  It is almost as bad as Sun's
>brain-damaged 386i line which forced its users to use YP, you could not
>even send MAIL without having YP running, but I digress. :-)
>
	It's a matter of how much time you can spend learning the system.
	We do fine but we had to take some time to learn it. Since alot
	of our business is SCO UNIX and Xenix it was worth our time to
	learn it.

	My point is that SCO UNIX differs in system administration and
	in some features advanced users would use if their shop
	doesn't provide other means; su and crontab. It's different but
	not necessarily evil or bad. Some of the SCO extentions are
	DAMN useful, others are a pain.
	
	You're waiting for SVR4, it'll be a MAJOR change from what you're
	used to and there is ALOT of new things to learn for system admin's
	and advanced users. If you think sysadmsh was "fun", wait till you
	see R4's equiv! Filesystem reorganization will be another fun change!
	And you can FORGET about online man pages... You also get the
	joys of following symlinks to symlinks to symlinks to ...

	SCO UNIX 3.2v2.0 is a useful UNIX system if you learn how security
	works. If you can't take the time to learn it, choose one of the
	other raw UNIX 3.2 systems. If you're comming up from Xenix,
	SCO UNIX softens the blow a bit.

	I think SCO UNIX's pluses outway the minus of the security
	system. I haven't seen much bashing not related to security,
	that seems to indicate to me that that's the main problem. The
	security can be tamed and the added value tools are useful
	for cross development. To each his own I guess...

	I just wanted to point out that there ARE sites that are
	using SCO UNIX and doing just fine. The security boogie
	man has more bark than bite.

		-Rob