SCO UNIX 3.2 Failure: df Command

[Brandon S. Allbery KB8JRR/KT]

I have comments on this.

As quoted from <9023 at scorn.sco.COM> by dionj at sco.COM (Dion L. Johnson):
+---------------
| The following letter is from SCO's UNIX product manager, Charley Watkins.
| 
| Dear Friend,
| 
| Your recent posting makes it clear that you are uncomfortable with
| the C2 security features in SCO UNIX System V/386.  Yours is a
| natural reaction, I think, to the ongoing adaptation of the UNIX
| system to the needs of end-users.  Sometimes this does mean
+---------------

Most end-users do not need security that, even in soi-disant "relaxed" mode,
is obtrusive.  I do not appreciate having created a user in singleuser mode
and now having that user forever stuck on /usr instead of /u with the others,
for example, because editing /etc/passwd is not permitted.

Even in relaxed mode, the system screams bloody murder about authorizations
when I attempt to add a shell to the sysadmsh menu.  Which I am trying to do
because you've managed to make it impossible to maintain the system in any
other way.

THIS I do not need.  This my company does not need.  I am close to
recommending we switch to 386/ix, and unless there are changes we will do so.

C2 SECURITY IS NOT NECESSARY IN MOST ENVIRONMENTS.  SCO Unix has group
vectors and other additions which can make a system secure enough for most
purposes when used correctly.  An always-active authorization database on most
of the files in the system, however, is *not* useful under most circumstances;
I should mention that we often customize systems even at the level of standard
system files, and my experience so far with the authorization database is that
we are now stuck with whatever we are delivered with.  Considering that SCO
has apparently decided to stick with such Xenix-isms as dialer programs (HDB
works quite well, thank you, unless you broke it) and a login program that
won't let you set environment variables like $TERM as you log in (try reading
a V.3.2 or even a V.3.1 login(1) man page some time), I would consider the
current system in need of such modifications --- which the system will not let
us perform.

+---------------
| incorporate C2 features, I think even the traditionalists among us
| will someday have to come to grips with the presence of C2 security.
+---------------

Have you ever heard of an "off switch"?  It's not necessary to have major
security features active on all systems at all times, and it should be
possible to turn *all* parts of it off.  The authorization database, which is
active even when "relaxed" security has been chosen, is looking to be a problem
in producing systems that do anything that you didn't happen to consider whne
putting it together.

Tradition be d*mned; I'm talking about systems that *work*, not systems that
scream PRIVILEGE VIOLATION!!!!!!!! when I put together a data collection
system.

---

Two more questions:

* MMDF is, to say the least, incomplete.  Why supply the /usr/lib/sendmail
  interface if you found it useful to leave out the srvrsmtp channel program?
  If you decided that's a network program, the question becomes "Why is
  /usr/lib/sendmail on a runtime system?"  And a second question is added:
  have you ever heard of mail user agents which want to talk to an SMTP
  sendmail in the absence of networking?

  Assuming the !@#$%^&* authorization database doesn't throw screaming fits
  at me, I'm going to replace the mail system with a fresh copy of mmdfIIb-43
  from louie.udel.edu.  End of *that* problem.

* I understand ksh is supposed to be part of the new system.  If that is not
  true, OK.  But if it *is* supposed to be there, why isn't it in the version
  for the Altos 5000?  Sour-grapes reasons are not acceptable.

++Brandon
not speaking officially for Telotech, Inc... yet.
-- 
Me: Brandon S. Allbery			    VHF: KB8JRR/KT on 220 (soon others)
Internet: allbery at NCoast.ORG		    Delphi: ALLBERY
uunet!usenet.ins.cwru.edu!ncoast!allbery    America OnLine: KB8JRR