Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!sco!dionj From: dionj@sco.COM (Dion L. Johnson) Newsgroups: comp.unix.i386 Subject: Re: SCO UNIX 3.2 Failure: df Command Summary: It's fixed. Keywords: help! Message-ID: <9023@scorn.sco.COM> Date: 10 Aug 90 20:37:54 GMT References: <135@happym.wa.com> Sender: news@sco.COM Reply-To: dionj@sco.COM (Dion L. Johnson) Organization: The Santa Cruz Operation, Inc. Lines: 102 In article <135@happym.wa.com> irv@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@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@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