SCO UNIX 3.2 Failure: df Command

[Irving Wolfe]

When I type "df" on my Motorola system, I get:
/u/spool/news(/dev/dsk/m320_1s2):    22142 blocks   10694 i-nodes
/u        (/dev/dsk/m320_1s1):    23572 blocks   11897 i-nodes
/usr/spool/uucp(/dev/dsk/m320_1s0):    22034 blocks    5975 i-nodes
/usr      (/dev/dsk/m320_0s1):    13384 blocks    7191 i-nodes
/         (/dev/dsk/m320_0s0):     3132 blocks    2067 i-nodes

When I type "df" on my SCO system, I get:
df: no authorization to query disk space.

I'm the system administrator, and have given myself every privilege, both
kernel and subsystem, that the obnoxious sysadmsh menu system will acknowledge
the existence of (with F3).

root has all the same privileges, and even with his total filesystem access
and no need for setuid, he gets the same error message.

1. Has anyone else experienced this?

2. I can't find anything in the df man page or the security section of the
system administrator's guide that would let me solve this myself.

3. I know that SCO, despite the rotten product and rotten support, has as 
least two top-quality technical employees, at least one of whom may read this 
newsgroup.  (You know who you are, and I appreciate your past help!  I'm only 
keeping your names quiet to protect your jobs, since my impression of SCO's 
management is that they'd fire you for helping someone without a service 
contract, even though the product simply doesn't work configured as sold.)  
If you know the answer, I'd appreciate your help once more, whether it's by
open posting or by private email.

4. I'm glad I bought a 630MB disk for this system, since I can't see when I'm
getting too full.

5. In the good old days -- before Intel, Microsoft, and SCO, just a few years
ago -- having UNIX meant being in control of your system, being able to make
it do anything you wanted it to, no matter how clever your demands.  Now it
seems that the roles are reversed.  The system is boss due to the really awful
security features that can't be fully disabled.  (They aren't effective
anyway, in the current release; only the bad parts were programmed, so there's
no payback in safety.  Besides, the biggest security risk to a 386 system is
someone carrying it off in his car.)  This power-trip role reversal might be 
a fine game in bed with your lover, but it's a rotten feature in an operating
system, especially one whose main virtue was giving the utmost in power and
convenience to the programmer.

So -- has any source code licensee or brilliant hacker out there written a
program that forces the /tcb files into conformity with an old-style (no
shadow) /etc/passwd file?  Would he be willing to share it with the world, or
with me?  I'd certainly be willing to pay to have this corruption of Unix
brought under my control, but perhaps you'd be willing to be a hero to
thousands of us out here, instead, and release it to a sources newsgroup?

6. One side issue, for any business-oriented readers:  I know my way around
computers, but I'm too busy running the business to manage the system and
write more than an occasional program.  So I have a full time, very organized
and competent man running things and doing most of our internal programming.
Neither of us is a Unix guru.  Especially _this_ Unix.  But between what I pay
him, and fringes and bonus, and what the time I personally put into this field
is worth, that's quite a bit of money, every year.  We could each save _at
least_ 30% of the time we spend on this system, maybe more, if it would just
be an old-fashioned Unix system that blindly obeyed us.  So the current
generation of sick twists in operating systems is costing us many times its
actual price -- every year -- in unnecessary professional time.  Why?  Is
there even one little thing we've gained from this?
-- 
 Irving Wolfe    Happy Man Corp.   irv at happym.wa.com    206/463-9399 ext.101
      4410 SW Point Robinson Road,  Vashon Island, WA  98070-7399
 SOLID VALUE, the investment letter for Benj. Graham's intelligent investors
 Information free (sample $10 check or credit card): email patty at happym.wa.com