irv@happym.wa.com (Irving Wolfe) (08/08/90)
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@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.competer@nixtdc.uucp (Peter Ziobrzynski) (08/09/90)
In <135@happym.wa.com> irv@happym.wa.com (Irving Wolfe) writes: >... >When I type "df" on my SCO system, I get: >df: no authorization to query disk space. We experience the same stuff here running SCO ODT1.0 (continuation of the SCO UNIX tradition). We think that ODT stands for the "Open Dust Bin" in free interpretation. Our problems with df are even more puzzling here because it happens only to some users while login accounts have been set up the same way by the single person. We haven't found the reason yet but my theory is that it may be due to some environment variables set or not set or uid being in some range - fiddle with your .login/.cshrc it may help. I also had a similar nonsense with csh core dumping in the .cshrc because of the "set path" being long (>160 chars). Your SCO impressions are pretty close to ours. -- Peter Ziobrzynski uucp: uunet!geac!nixtdc!peter Nixdorf Toronto Development Center 416 496-8510
dionj@sco.COM (Dion L. Johnson) (08/11/90)
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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/12/90)
I have comments on this. As quoted from <9023@scorn.sco.COM> by dionj@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@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR
nvosd@nwnexus.WA.COM (UW West ) (08/12/90)
Well, time for my $.02 here - I'm also a fairly new user of SCO Sys V, and I guess I've got to agree with BOTH previous postings. Yes, C2 security is somewhat painful to those of us who "grew up" without it, and yes, SCO has been having some growing pains. BUT, I think we need to give credit to SCO (esp Charley and a few others) who really seem to be TRYING to keep things headed in the right direction. I've been really pleased with the "front line" folks at SCO, and their response, AND with their management's willingness to back 'em up when they "do the right thing" for a customer. There are a lot of companies out there that are nowhere near as good at this as SCO. My only complaints with SCO are that their prices seem a bit high for olks who want to get started, and don't have the "big bucks". Clay Jackson
rick@crash.cts.com (Rick Stout) (08/12/90)
In article <135@happym.wa.com> irv@happym.wa.com (Irving Wolfe) writes: >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. > This bit me too. The solution in my case was really simple and annoying. check the ownership, group, and mode of /bin/df. it should be: ---x--s--x owner:bin group:backup In my case all was correct except group was 'other' or something. Upon changing to backup, it worked fine. -Rick ________________________________________________________________________________ Rick Stout ...uunet!eysd!rick Ernst & Young, San Diego (619) 236-1100 ================================================================================
irv@happym.wa.com (Irving Wolfe) (08/14/90)
HOORAY FOR RICK STOUT!
Rick's answer -- chgrp backup /bin/df -- solved the problem.
I'd gotten a number of flames and compliments, both posted and emailed, from
SCO and from its customers, and even a couple of suggestions, but this simple
bit of advice
(a) was completely clear and not vague; and
(b) solved the problem.
Thanks, expert!
--
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