SCO UNIX 3.2 Failure: df Command

Dion L. Johnson dionj at sco.COM
Sat Aug 11 06:37:54 AEST 1990


In article <135 at happym.wa.com> irv at happym.wa.com (Irving Wolfe) writes:
[I hope Mr. Wolfe will forgive some editing of his posting. -Dion :-) ]
[problems with df command]
 >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 
[We had a lot of fun kidding our managers about this... :-) ]
 >contract, even though the product simply doesn't work configured as sold.)  
[asks for help ]
 >
[discomfort with security functions... ]
 >
[solicits rewrite of SCO UNIX to "undo" the C2 features... ]
[feels that security features cost too much time... ]
 >-- 
 > 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
--------------------------------------
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
imposing some inconveniences on the expert user, and maybe some
aspects of C2 security in the original version of SCU UNIX were
more inconvenient than they had to be.  I apologize for not getting
it exactly right in the first release.

I can also see your point about our decision to include C2 security.
For someone who has mastered the internals of the system and who
is accustomed to administering a system without the aid of a menu
shell, all the new C2 facilities must seem rather confining.
However, to end-users who rely on the simplified system management
tools provided with SCO UNIX System V/386, dealing with security
is just as natural as performing regular backups.  And to many
end-users, especially those who are just now adopting UNIX, security
of the operating environment is an overriding concern.  Application
developers who wish to sell into this market--which includes most
purchases by the US government--will find they need to provide for
C2-trusted operation of their products.  As more and more UNIX systems
incorporate C2 features, I think even the traditionalists among us
will someday have to come to grips with the presence of C2 security.

We're sorry you've had to share in our ''growing pains'', but we
hope you will judge us more on our willingness to listen to your
complaints and take action on them than on the rough edges of our
initial product offering.  Maybe we should have taken longer to put
a little more polish on the first version of SCO UNIX, but there
were thousands of end-users out there with an immediate requirement
for a C2-trusted UNIX and we felt we should respond to their needs,
too.  Perhaps it was inevitable that some aspects of the initial
product release did not match the needs of expert developers.

In any case, we _have_ listened and we have learned where management
of C2-trusted systems can be streamlined.  As a result, Version 2.0
of SCO UNIX System V/386 Release 3.2 can be configured for more
traditional UNIX system behavior at installation time or later using
the SCO system administration shell (sysadmsh).  In the ''relaxed'' mode,
auditing can be suspended and even ordinary users can have setuid privileges.
Authorizations, password limitations, login limitations,
and even the default umask can be ''relaxed'' for individual users or
across the board.

In your example, where df previously failed, the following sysadmsh
sequence would allow you to set the queryspace authorization needed
to allow use of df:

Accounts --> User --> Examine :  Privileges

Please note that ''queryspace'' authorization is the out-of-the-box
default.  It seems likely that you inadvertantly overrode the default,
possibly by defining a new user without the system default authorities.
You can learn more about it by reading the SUBSYSTEM(M) man page.
We hope that you will take another look at SCO UNIX System V/386
and let us know whether we have made progress on addressing your
concerns.  Also let us know where there are still rough spots so we
can see about smoothing them out.  We really don't intend to prevent
experts from having their way with the system, but after all it is
concern about unrestricted access by unscrupulous experts that has
led to the end-user requirement for UNIX security.

At risk of undue commercialism, I feel obliged to point out that
Version 2.0 of SCO UNIX System V/386 Release 3.2 is now shipping on
3.5" and 5.25" media, both as a complete product and as a low-cost
update to the original version.  If, for some reason, it is not now
practical to move to Version 2.0, you can obtain most of the C2-level
security enhancements as SLS unx223 for the original version at no cost
from either our support department or from the BBS.

Truly Yours,

Charley Watkins
SCO UNIX Product Manager



More information about the Comp.unix.i386 mailing list