chip@tct.uucp (Chip Salzenberg) (11/27/90)
According to ronald@robobar.co.uk (Ronald S H Khoo): >SCO Unix, on the other hand is a different kettle of fish altogether. >... because they've completely changed the semantics of just about >everything so much (because of their "security" <barf> "enhancements") >so it might be fair to call SCO Unix "Not a real Unix". I completely agree. C2 security cannot be disabled on "SCO Unix" systems. It can be "relaxed," but that's not the same as "disabled." The "SCO Unix" product is actually "SCO Unix-Flavored C2 Operating System." We used Xenix here at TCT for some time. When we were about to take the plunge into Unix, we asked the salescritters if the C2 security could be disabled. They *lied*: they said "Yes." Perhaps the salescritters knew no better. However, I believe that they expected C2 security without an "off" switch to be very unpopular with us developers -- you know, the people that write the software that sells the OS. So they told us what we wanted to hear. Unless we, the developers and users, keep the pressure on SCO, there will never be a C2-free version of "SCO Unix." And that would be a pity. Let's keep reminding them of what we want. You know, TCT might have bought many more copies of SCO Unix... If only SCO sold a Unix-compatible version. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I've been cranky ever since my comp.unix.wizards was removed by that evil Chip Salzenberg." -- John F. Haugh II
tneff@bfmny0.BFM.COM (Tom Neff) (11/28/90)
In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Unless we, the developers and users, keep the pressure on SCO, there >will never be a C2-free version of "SCO Unix." And that would be a >pity. Let's keep reminding them of what we want. With all due respect, I'm still wondering why the marketplace so desperately needs a fixed SCO UNIX in particular. There are only about seven other vendors out there, just about all of whom do it right. You have the vanilla AT&T/Intel branch and then the value-added Interactive derivatives, in all kinds of price ranges and with all sorts of hardware and software support arrangements. Other than for the sake of blind Neanderthal die-hard hold-over (misplaced) product loyalty from the utterly different days of that utterly different product Xenix, or out of sheer customer ignorance of any other name, why the @*&#$^ does anyone care *what* SCO does? UNIX is a commodity: take your best deal. -- The most common given name in the world is Mohammad; | Tom Neff the most common family name in the world is Chang. | Can you imagine the enormous number of people in the | tneff@bfmny0.BFM.COM world named Mohammad Chang? -- Derek Wills | uunet!bfmny0!tneff
palowoda@fiver (Bob Palowoda) (11/29/90)
From article <16068@bfmny0.BFM.COM>, by tneff@bfmny0.BFM.COM (Tom Neff): > In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Unless we, the developers and users, keep the pressure on SCO, there >>will never be a C2-free version of "SCO Unix." And that would be a >>pity. Let's keep reminding them of what we want. > > With all due respect, I'm still wondering why the marketplace so > desperately needs a fixed SCO UNIX in particular. There are only about > seven other vendors out there, just about all of whom do it right. You > have the vanilla AT&T/Intel branch and then the value-added Interactive > derivatives, in all kinds of price ranges and with all sorts of hardware > and software support arrangements. Other than for the sake of blind > Neanderthal die-hard hold-over (misplaced) product loyalty from the > utterly different days of that utterly different product Xenix, or out > of sheer customer ignorance of any other name, why the @*&#$^ does > anyone care *what* SCO does? UNIX is a commodity: take your best deal. Let me take a guess who. The new customers of coarse. The way I see it is that nobody in the marketplace cared enough to write about fixing a certain version of UNIX inconsistent features, bugs, what XY company want's to do about it UNIX would not be as much as a commodity that it is today. I guess if we stop talking about the problems we would have more "customer ignorance". Is that the type of marketplace you want? You know with several version of UNIX out there the potenial alot of potential new customers cannot afford to run out and buy one of each run benchmarks, test apps, compatiblity, and find out what works all in a reasonable period of time and/or cost. Sure they can read sales lit, and check out the latest UNIX magazine articles but what if they want to hear about if something needs to get fixed? Magazines? Give me a break. ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
ronald@robobar.co.uk (Ronald S H Khoo) (11/29/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: > With all due respect, I'm still wondering why the marketplace so > desperately needs a fixed SCO UNIX in particular. > why the @*&#$^ does > anyone care *what* SCO does? UNIX is a commodity: take your best deal. The annoying thing is that there are some things that SCO does quite well, like the support of a large range of hardware. (Quick aside: can any of the other unices support 4 ST-506 style interface discs *and* a SCSI on an AHA1540 at the same time? This is a *serious* question which I'd like the answer to, please!) And of course, if you absolutely need MS-DOS/OS-2 cross development, they are the only game in town. Also, it can be quite hard to persuade "the management" that the "best buy of the century has changed". "You told us SCO was the best 3 years ago, did you get it wrong then?" etc. And what about hardware vendors who lock you in to SCO UNIX like Altos and Compaq (for Compaq dual-processor systems). You gotta admit that SCO unbreaking their UNIX would be helluva convenient for loadsa guys. Me, I'm gonna *have* to look at the competition. I still happen to think that their Xenix is just about the best UNIX you can get for 386 boxes. Rock solid, stingy on core and disc (what System Vr3.2 compatible OS can you think of that'll be *happy* in 2 Meg of core and 20 Meg of disc and still have space left over for the users?) but their native 3.2 product is unuseable. And no one in their right mind would depend on Xenix in the future -- not even SCO know exactly how far they are going to keep maintaining it! -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
larry@nstar.rn.com (Larry Snyder) (11/30/90)
ronald@robobar.co.uk (Ronald S H Khoo) writes: >Me, I'm gonna *have* to look at the competition. I still happen to think >that their Xenix is just about the best UNIX you can get for 386 boxes. >Rock solid, stingy on core and disc (what System Vr3.2 compatible OS but the disk IO is doggie slow - compared to the Unix's available - Xenix is like you say - lean and solid - and supported (and provides good serial throughput without requiring smartboards).. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, {uunet|backbone}!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
rhealey@digibd.com (Rob Healey) (11/30/90)
In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to ronald@robobar.co.uk (Ronald S H Khoo): >>SCO Unix, on the other hand is a different kettle of fish altogether. >>... because they've completely changed the semantics of just about >>everything so much (because of their "security" <barf> "enhancements") >>so it might be fair to call SCO Unix "Not a real Unix". > >I completely agree. > >C2 security cannot be disabled on "SCO Unix" systems. It can be >"relaxed," but that's not the same as "disabled." The "SCO Unix" >product is actually "SCO Unix-Flavored C2 Operating System." > Ok, I'll bite. What IS a "real" UNIX? Minus the security SCO UNIX 3.2v2.0 seems pretty damn 3.2 to me, as much as any other "UNIX" system that claims 3.2. Isn't there a little problem with AT&T lawyers if you use "UNIX" in the name of your product and it isn't 3.2 or 4.x "certified"? Aside from the fact that everyone seems to have joyous glee in bashing SCO as often as possible and the security fiasco, WHAT in SCO UNIX 3.2v2 makes it incompatable with 3.2 from a user's point of view? I program on a SCO UNIX 3.2v2 box and security hasn't bothered me or my programs that much; i.e. gcc, gas, gdb and the usual development tools. SCO isn't being sued by AT&T for misuse of the UNIX name so why isn't it a 3.2 type UNIX? 1) I can see where using an ANSI compiler might screw up old time C programmer's code that uses uncasted incompatable types with wild abondon. 2) Drivers are obviously different. That can be good and bad. 3) POSIX conformance creates some fun with signals, job control and tty related stuff. But that will be a problem on ANY OS that is POSIX conformant. I've done the first 3, now all you bashers who have obviously spent more time on SCO UNIX 3.2v2 than me fill in the rest! I anxiously await all the things I should watch out for. -Rob Speaking for self, not company.
tneff@bfmny0.BFM.COM (Tom Neff) (11/30/90)
In article <1990Nov29.064438.3206@fiver> palowoda@fiver (Bob Palowoda) writes: > The way I see >it is that nobody in the marketplace cared enough to write about fixing >a certain version of UNIX inconsistent features, bugs, what XY company >want's to do about it UNIX would not be as much as a commodity that it >is today. HELP!! HELP!! I am trapped in the above sentence!! I can't get it out of my brain!! HEEEEEEELLLLL...... >>spphhutt<<
chip@tct.uucp (Chip Salzenberg) (11/30/90)
According to tneff@bfmny0.BFM.COM (Tom Neff): >In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Unless we, the developers and users, keep the pressure on SCO, there >>will never be a C2-free version of "SCO Unix." And that would be a >>pity. Let's keep reminding them of what we want. > >With all due respect, I'm still wondering why the marketplace so >desperately needs a fixed SCO UNIX in particular. What a good question! Let me enumerate some reasons: 1. Installed base. We're a SCO shop for some time, and we've installed SCO Xenix and SCO Unix at several customers. OS vendor changes are always more or less traumatic, and we must still support our installed customer base. It would be infinitely preferable to get a C2-free SCO UNIX, so we don't have to go through a massive changeover. 2. Equal support for ISA and Micro Channel. Because of our business partners, who are Really Big Companies, we're stuck with the very conservative and non-negotiable stand that we *will* sell IBM hardware. Thus we're stuck with the PS/2 Model 80. Since our primary development machine is an ISA bus Compaq Deskpro, we obviously prefer to have one OS that runs on both the Compaq and the PS/2. The only current alternative to SCO with this feature is Interactive, and the advantages of Interactive (no C2) are outweighed by its disadvantages (poor support, requires vendor change). 3. Support. No, SCO support isn't perfect. But the fact remains that when they identify something as a bug, they fix it for free, and they put the fixes on a publicly accessible archive machine. You can't beat that with a stick. And once you find the knowledgable people, they're friendly and helpful. CONCLUSION: Switching from SCO to another vendor will be a painful experience. We're trying to avoid it. Still, if it must be done, it will be done. If a vendor of System V Release 4 for ISA machines comes out with a Micro Channel version, I'll bet dollars to donuts that we'll buy their product. Assuming that doesn't happen, I'll motivate management to buy Dell Unix for the Compaq machine and AIX for the PS/2. Yet -- we could avoid all this pain, if only SCO would sell UNIX... -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I've been cranky ever since my comp.unix.wizards was removed by that evil Chip Salzenberg." -- John F. Haugh II
fred@cdin-1.UUCP (Fred Rump) (12/01/90)
chip@tct.uucp (Chip Salzenberg) writes: >According to tneff@bfmny0.BFM.COM (Tom Neff): >>In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>>Unless we, the developers and users, keep the pressure on SCO, there >>>will never be a C2-free version of "SCO Unix." And that would be a >>>pity. Let's keep reminding them of what we want. >It >would be infinitely preferable to get a C2-free SCO UNIX, so we don't >have to go through a massive changeover. Somewhere along the line we are missing the problem. So we're a SCO shop too. We've 'upgraded' some customers to SCO UNIX from Xenix. We relaxed C2. So what's the big deal? The customer doesn't even know the difference. He didn't know beans about Xenix and he won't know beans about UNIX. He simply uses the menu to do real work. This whole discussion escapes me. From the end-user's, what's the difference? >2. Equal support for ISA and Micro Channel. >Because of our business partners, who are Really Big Companies, we're >stuck with the very conservative and non-negotiable stand that we >*will* sell IBM hardware. Thus we're stuck with the PS/2 Model 80. Sorry about that. I guess our customers aren't really that big to insist on labels just yet. In the small business world the onus seems to be on cost-performance. >3. Support. >No, SCO support isn't perfect. But the fact remains that when they >identify something as a bug, they fix it for free, and they put the Not so fast here. Some of our reported bugs are several years old. But, in general, I agree. Without proper support we'd be dead in the water. This is probably one of SCO's biggest operating expenses and their prices reflect some of this. >CONCLUSION: >Switching from SCO to another vendor will be a painful experience. >We're trying to avoid it. Still, if it must be done, it will be done. Whatever SCO does will still be the product that drives the market and others will adjust to it. Witness any compatibility 'arrangement' and who's involved. At this point we feel perfectly comfortable going with the flow of SCO. I will let the hackers argue bits and bytes but the bottom line is what counts to make their paychecks out every week. To me it seems that there is some safety in numbers. Fred -- Fred Rump | Home of Brother John Software CompuData, Inc. | 10501 Drummond Rd. | Bang: {uunet dsinc}!cdin-1!fred (800-223-DATA) Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
sef@kithrup.COM (Sean Eric Fagan) (12/01/90)
In article <2332@cdin-1.UUCP> fred@cdin-1.UUCP (Fred Rump) writes: >The customer doesn't even know the difference. He didn't know beans about >Xenix and he won't know beans about UNIX. >He simply uses the menu to do real work. >This whole discussion escapes me. From the end-user's, what's the difference? Uhm, just because *your* customers don't see the difference doesn't mean other customers don't, either. For example, I just installed C News on kithrup, and initially could not have automatic unbatching because spacefor wasn't being allowed to run df! Why? Because, even though kithrup is relaxed (*very* relaxed, almost dead 8-)), account news didn't get queryspace priviledges by default. That's one of about a dozen or so things I've run into. >>Switching from SCO to another vendor will be a painful experience. >>We're trying to avoid it. Still, if it must be done, it will be done. Now, to make a counterpoint, I should point out that administering kithrup is relatively easy. I think I run into a uucp problem every once in a while (but I'm fairly certain that that is a hardware problem [flaky modem], not a software one), but that's about it. Kithrup has crashed twice, once because of misinstalling a tape drive (oops 8-(), and once for a still unknown reason. Running 3.2v2, kithrup is about as fast for most things as it was when running Xenix, and faster in other things. And I've got the Rand Mail Handler running, with emacs, and job control, and networking. Although I'd like to see the kernel smaller by about 500k, it still suits me just fine. -- -----------------+ Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/02/90)
As quoted from <16068@bfmny0.BFM.COM> by tneff@bfmny0.BFM.COM (Tom Neff): +--------------- | In article <27519123.34A2@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: | >Unless we, the developers and users, keep the pressure on SCO, there | >will never be a C2-free version of "SCO Unix." And that would be a | >pity. Let's keep reminding them of what we want. | | With all due respect, I'm still wondering why the marketplace so | desperately needs a fixed SCO UNIX in particular. There are only about | seven other vendors out there, just about all of whom do it right. You +--------------- Because of all the companies with "IBM syndrome" (including Altos, d*mn them!) who will only accept those three magic letters, in this case "SCO". In the case of Altos, I know for a fact that they're getting raked over the coals by buyers of the Series 5000 because of Altos's decision to go with SCO UNIX; but they're bound and determined to stay with SCO because it's SCO (you'd think that was the spelling for "God"). And *we* have no choice in the matter unless we want to go with less trustworthy third-party add-ons (in particular, I have yet to see a third-party serial port board that was stable). I'm just about at the point where I'm ready to start evaluating third-party hardware looking for something that *does* work, and switch to a real UNIX. SCO "UNIX" isn't. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/02/90)
As quoted from <2332@cdin-1.UUCP> by fred@cdin-1.UUCP (Fred Rump): +--------------- | This whole discussion escapes me. From the end-user's, what's the difference? +--------------- Try developing on the d*mned thing. +--------------- | Whatever SCO does will still be the product that drives the market and others | will adjust to it. Witness any compatibility 'arrangement' and who's involved +--------------- Not this time; SCO Pseudnix is getting bashed by more people than just a few Usenetters. SCO will get a clue *or* the same thing will happen to them as happened to IBM in the PC market: they will be bought only by hard-cores (like Chip is stuck with) while the rest of the market switches to something else. +--------------- | I will let the hackers argue bits and bytes but the bottom line is what counts | to make their paychecks out every week. +--------------- True. We have to deliver product to get money for our paychecks, and SCO Pseudnix is doing everything it can to make that impossible. I suspect Chip's in a similar predicament. This is supposed to be an *advantage*? ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/02/90)
As quoted from <1990Nov29.205938.3671@digibd.com> by rhealey@digibd.com (Rob Healey): +--------------- | Ok, I'll bite. What IS a "real" UNIX? Minus the security +--------------- That's half the problem right there. Just as Chip said --- C2 *unrelaxable* security breaks the semantics of nearly everything. And I *do* mean ***UNRELAXABLE*** --- no matter what SCO tells you about "relaxed security", you can't tell the kernel not to use luid's and therefore you can't "su" except under certain circumstances (i.e. you can't "su news" unless you are root or the SINGLE non-root account that is allowed to "su" to a maintenance account). +--------------- | SCO UNIX 3.2v2.0 seems pretty damn 3.2 to me, as much as | any other "UNIX" system that claims 3.2. Isn't there a little | problem with AT&T lawyers if you use "UNIX" in the name of your | product and it isn't 3.2 or 4.x "certified"? +--------------- SCO enjoys claiming adherence to zillions of standards with everything in place to back that up, while managing to be non-standard nonetheless. * uucp --- everyone else is running HoneyDanber or at least SVR2 UUCP, which gets 8-character UUCP names right. SCO is still running V7 UUCP --- I admit they have HDB-ized it, but it *still* doesn't transfer anything when I "uucico -stelotech", I MUST say "uucico -stelotec" to make it work. And yes, both the actual machine name and the Systems file entry are "telotech" WITH the "h". * grep --- why should I have to remember that, ouyt of all the System V machines in the office, only the SCO Pseudnix machine uses "-y" to do case- ignored searches? All the others use "-i". There are more examples; I have a long list at work describing differences between SCO Pseudnix and UNIX. +--------------- | I've done the first 3, now all you bashers who have obviously spent | more time on SCO UNIX 3.2v2 than me fill in the rest! +--------------- None of those three are problems (modulo terminal hangs when an unsuspecting person who's heard of job control does "stty susp '^Z'" from csh, runs something, types "^Z" and hangs the tty). The biggest problem I have encountered is maintenance. SCO Pseudnix maintenance is so different from UNIX maintenance that it must be classed as a completely different entity. Now, maybe you leave the maintenance to someone else and stick to programming; if so, lucky you. *I* get to do maintenance, as well as programming. And when another programmer started using the SCO Pseudnix box, it took him all of five minutes to start running into security- related hassles --- on a machine on which I did everything I could to relax security within a half hour after getting it into the office. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
sef@kithrup.COM (Sean Eric Fagan) (12/02/90)
In article <1990Dec1.225346.16828@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >* grep --- why should I have to remember that, ouyt of all the System V > machines in the office, only the SCO Pseudnix machine uses "-y" to do case- > ignored searches? All the others use "-i". Your other complaints may be valid, but: kithrup 428$ echo "Hello" > /tmp/foo.$$ kithrup 429$ grep -i hel /tmp/foo.$$ Hello This is 3.2v2, a much better implementation than 3.2.0 or ODT 1.0... >None of those three are problems (modulo terminal hangs when an unsuspecting >person who's heard of job control does "stty susp '^Z'" from csh, runs >something, types "^Z" and hangs the tty). Hmm. Does sound as if you are not running 3.2v2. Job control there works rather nicely (although I occasionally find that my susp character has disappeard; I don't have any way of reliably reproducing that, though, and I suspect it's emacs). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
calhoun@usaos.uucp (Warren D. Calhoun) (12/03/90)
In <1990Dec1.225346.16828@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >* uucp --- everyone else is running HoneyDanber or at least SVR2 UUCP, which > gets 8-character UUCP names right. SCO is still running V7 UUCP --- I admit > they have HDB-ized it, but it *still* doesn't transfer anything when I > "uucico -stelotech", I MUST say "uucico -stelotec" to make it work. And yes, > both the actual machine name and the Systems file entry are "telotech" WITH > the "h". Why does uucico -r1 -Ssystemxx (eight characters) work for me? Granted, the directory in /usr/spool/uucp is called systemx and the log file entries all contain the name systemx, but the transfer works. -- | SSG W.D. Calhoun | UUCP: ...!uunet!usaos!calhoun | | Gas Turbine Engine (52F) Branch | INTERNET: calhoun%usaos@uunet.uu.net | | The U.S. Army Ordnance School | CompUServe: 76336.2212@compuserve.com | | Fort Belvoir, Virginia 22060 | Voice: (703) 664-3396/3595 |
brown@ka3ovk.irs.GOV (Ken Brown) (12/03/90)
In article <1990Dec1.225346.16828@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: > >There are more examples; I have a long list at work describing differences >between SCO Pseudnix and UNIX. > >+--------------- >| I've done the first 3, now all you bashers who have obviously spent >| more time on SCO UNIX 3.2v2 than me fill in the rest! >+--------------- > I've got another one. As part of SysV, AT&T in their infinite wisdom decided to move the mail spool directory from /usr/spool/mail to /usr/lib/mail. Seemed like a strange move to me, with no obvious benefits but, hey, it was their baby. They can do as they wish. SCO comes along and decides to move it back to /usr/spool/mail. This means that it is no longer safe to install mailers on SCO systems since the install programs will assume that SCO is SysV UNIX and default to the SysV standard. I'm not sure who I'm more pissed at -- AT&T for deciding to 'fix' something that wasn't broken, or SCO for deciding that they knew the 'right' way to do things -- thereby creating Pseudnix (I love that word).
gorpong@ping.uucp (Gordon C. Galligher) (12/03/90)
In article <1990Dec01.061344.6240@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: [..Administrating SCO unix...] >is relatively easy. I think I run into a uucp problem every once in a >while (but I'm fairly certain that that is a hardware problem [flaky modem], >not a software one), but that's about it. Kithrup has crashed twice, once >because of misinstalling a tape drive (oops 8-(), and once for a still >unknown reason. You have obviously not used Shell Layers. If you use shell layers and create a sub-shell and then execute 'stty intr \^c' it kills the shell. If you forget that '^' is a synonym for ';' in SH, and you execute 'stty intr ^c' it REBOOTS THE MACHINE! I sent mail to the SCO mailing list, and although SCO representatives have been vocal before, they were remarkably silent about it. (PS: I used shell layers quite extensively on Interactive's and was "a tad miffed" when SCO rebooted my machine (with NO errors, I might add). I would much rather use real job control, but ....) I am now waiting for SVR4 from Intel to show up RSN. (I have to admit, when SCO UNIX first came out, I ditched Interactive's for SCO (because some of the things looked nice) but the honeymoon did not last very long and I am hoping that SVR4 will not let me down.) -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 ...!{uupsi,uu.psi.com}!ping!gorpong
gorpong@ping.uucp (Gordon C. Galligher) (12/03/90)
In article <1990Nov29.205938.3671@digibd.com> rhealey@digibd.com (Rob Healey) writes: > Aside from the fact that everyone seems to have joyous > glee in bashing SCO as often as possible and the security > fiasco, WHAT in SCO UNIX 3.2v2 makes it incompatable with > 3.2 from a user's point of view? I program on a SCO UNIX 3.2v2 Have you used the crontab of SCO's unix? Have you used the 'df' program of SCO's unix? Have you used the su of SCO's unix? All of these things are not 'standard' UNIX, even with C2 security relaxed. You cannot 'su' to root (or anyone else) unless you mess with the tcb/auth/crap files manually. If you finally are successful in su'ing to root, you are really NOT root. You cannot do things like change user's passwords (unless your LOGIN-ID has a special thing set up on tcb/auth/crap, and then you can be the normal user and STILL change other's passwords). If you 'su' to another user, you cannot use 'crontab' which breaks things like: su uucp -c 'crontab /tmp/crontab'. This is all things which are done in a user's point of view (yes, users DO use the 'su' command, well, er, they DID before SCO "unix" came out...). You may say that this is the security thing; well, yes it is. The problem is, SCO has made the security TOO much a part of the entire operating system. Merely 'relax'ing security in the sysadmsh is not enough. Too many programs expect it to be running. It is almost as bad as Sun's brain-damaged 386i line which forced its users to use YP, you could not even send MAIL without having YP running, but I digress. :-) -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 ...!{uupsi,uu.psi.com}!ping!gorpong
sef@kithrup.COM (Sean Eric Fagan) (12/03/90)
In article <1990Dec02.213409.17190@ka3ovk.irs.GOV> brown@ka3ovk.irs.GOV (Ken Brown) writes: >SCO comes along and decides to move it back to /usr/spool/mail. This means >that it is no longer safe to install mailers on SCO systems since the >install programs will assume that SCO is SysV UNIX and default to the >SysV standard. Well, under 3.2 uses (by default) MMDF, so any "correct" program should take a look at /usr/mmdf/mmdftailor, and get file correct definitions. (MDLVDIR specifies the directory, MMBXNAME is the name of the file.) I must admit, I haven't gotten around to making MH deal with these yet, but it is a goal. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/03/90)
In article <1990Dec3.044437.21678@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: >You have obviously not used Shell Layers. Before tonight, the last time I tried shell layers was about 3.5 years ago. On a 3B5... But, since I was curious, and nothing was scheduled to happen on kithrup for a few minutes at least, I rebuilt my kernel, rebooted, and tried it. My shell didn't terminate, and my system didn't crash. I suspect it is merely one of the (unfortunately many) problems that was fixed in 3.2v2. I recommend you get the update... >If you forget that '^' is a synonym for ';' in SH, and you execute 'stty >intr ^c' it REBOOTS THE MACHINE! Actually, in pre-ksh, '^' is a synonym for '|'. But I get your drift 8-). >I sent mail to the SCO mailing list, and although >SCO representatives have been vocal before, they were remarkably silent >about it. I saw your message, and, yeah, I was somewhat curious about the lack of response. Which is why I went to all that effort to reconfigure my machine and reboot. (tongue somewhat in cheek there...) >I would much rather use real job control, but ....) Ah. You *definitely* aren't running 3.2v2. In 3.2.0 and 3.2.1 (aka ODT 1.0, I believe), job control is there, but doesn't work. In 3.2v2, however, job control is present, and ksh is shipped with the system (I use it myself). I'm quite satisfied with the job control (as I pointed out in my message, to which you followed up, I believe), and it *is* "real job control." Before you ditch SCO, please let me urge you to consider getting 3.2v2. It's not perfect (nothing is), but it's a lot better than 3.2.0. I'm running it at home, for example, which I wouldn't do if I didn't think it was worth it (I'd run xenix instead, which I did for quite a while). Any of the above pertaining to trying to push SCO should be read under the consideration that, in my other life, I work for SCO. The stuff about it working udner 3.2v2, however, was written by someone who merely was able to reconfigure a system, so should be read in a different light. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
shwake@raysnec.UUCP (Ray Shwake) (12/04/90)
brown@ka3ovk.irs.GOV (Ken Brown) writes: >I've got another one. As part of SysV, AT&T in their infinite wisdom >decided to move the mail spool directory from /usr/spool/mail to >/usr/lib/mail. Seemed like a strange move to me, with no obvious benefits >but, hey, it was their baby. They can do as they wish. The mail spool directory back in the Version VII and, if I'm not mistaken System III, days *was* in /usr/spool/mail. Since at least System V it's been in /usr/mail, and *still is* for ISC UNIX and, if I'm not mistaken, AT&T UNIX 386. >SCO comes along and decides to move it back to /usr/spool/mail. This means >that it is no longer safe to install mailers on SCO systems since the >install programs will assume that SCO is SysV UNIX and default to the >SysV standard. Both SCO Xenix and SCO UNIX have *always* used /usr/spool/mail. Sun and many BSD-based systems have followed that same convention. Perhaps once Intel, ATT, ISC and SCO get together on the next UNIX 386 binary standard they will clear up these and other subtle differences.
fred@cdin-1.UUCP (Fred Rump) (12/04/90)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <2332@cdin-1.UUCP> fred@cdin-1.UUCP (Fred Rump) writes: >>This whole discussion escapes me. From the end-user's, what's the difference? >Uhm, just because *your* customers don't see the difference doesn't mean >other customers don't, either. >For example, I just installed C News on kithrup, and initially could not >That's one of about a dozen or so things I've run into. Come on now. Of the sales going into the typical end-user shop how many do you think can or will install news themselves? Any site that is at that level should have no trouble at all with the idiosyncracies of a relaxed SCO UNIX. I don't still don't think it makes a hell of a lot of difference to 90% of the sites out there. Fred -- Fred Rump | Home of Brother John Software CompuData, Inc. | 10501 Drummond Rd. | Bang: {uunet dsinc}!cdin-1!fred (800-223-DATA) Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
fred@cdin-1.UUCP (Fred Rump) (12/04/90)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >As quoted from <2332@cdin-1.UUCP> by fred@cdin-1.UUCP (Fred Rump): >+--------------- >| This whole discussion escapes me. From the end-user's, what's the difference? >+--------------- >Try developing on the d*mned thing. See above. I don't expect end user sites to be into the software development business. Here we still do all development on Xenix but sell and install the code under SCO UNIX. Those users we've changed from Xenix to UNIX still don't see any change. Fred -- Fred Rump | Home of Brother John Software CompuData, Inc. | 10501 Drummond Rd. | Bang: {uunet dsinc}!cdin-1!fred (800-223-DATA) Philadelphia, Pa. 19154| Internet: fred@COMPU.COM (215-824-3000)
chip@tct.uucp (Chip Salzenberg) (12/04/90)
According to rhealey@digibd.com (Rob Healey): > Ok, I'll bite. What IS a "real" UNIX? Minus the security > SCO UNIX 3.2v2.0 seems pretty damn 3.2 to me ... Oh, I quite agree. SCO "UNIX", minus C2, would be real Unix. Unfortunately, that's not a product SCO sells. I agree with Sean Fagan that SCO's system administration tools are fairly easy to use. However, they are only required because of C2, a "feature" that we don't want. Administration tools are useful on any UNIX system, true; but they are *required* under SCO "UNIX" because the C2 security requires that lots of auxiliary files be munged in coordination with chnages to /etc/passwd, /etc/group, etc. To put the matter succinctly (if somewhat too kindly), I will repeat about SCO "UNIX" what someone else said about APL: SCO C2 "UNIX" is a mistake carried through to perfection. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I'm really sorry I feel this need to insult some people..." -- John F. Haugh II (He thinks HE'S sorry?)
chip@tct.uucp (Chip Salzenberg) (12/04/90)
According to allbery@ncoast.ORG (Brandon S. Allbery KB8JRR): >Not this time; SCO Pseudnix is getting bashed by more people than just a few >Usenetters. SCO will get a clue *or* the same thing will happen to them as >happened to IBM in the PC market: they will be bought only by hard-cores >(like Chip is stuck with) while the rest of the market switches to something >else. An eloquent description of my current situation, and my expectations. Wake up, SCO, and smell the coffee. We developers don't like SCO UNIX-flavored C2 Operating System. When we are given the chance, we'll buy something else. How long can you last without third-party development? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I'm really sorry I feel this need to insult some people..." -- John F. Haugh II (He thinks HE'S sorry?)
jdeitch@jadpc.cts.com (Jim Deitch) (12/04/90)
In article <1990Dec02.213409.17190@ka3ovk.irs.GOV> brown@ka3ovk.irs.GOV (Ken Brown) writes: >In article <1990Dec1.225346.16828@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >> >>There are more examples; I have a long list at work describing differences >>between SCO Pseudnix and UNIX. >> >>+--------------- >>| I've done the first 3, now all you bashers who have obviously spent >>| more time on SCO UNIX 3.2v2 than me fill in the rest! >>+--------------- >> > >I've got another one. As part of SysV, AT&T in their infinite wisdom >decided to move the mail spool directory from /usr/spool/mail to >/usr/lib/mail. Seemed like a strange move to me, with no obvious benefits >but, hey, it was their baby. They can do as they wish. > >SCO comes along and decides to move it back to /usr/spool/mail. This means >that it is no longer safe to install mailers on SCO systems since the >install programs will assume that SCO is SysV UNIX and default to the >SysV standard. > >I'm not sure who I'm more pissed at -- AT&T for deciding to 'fix' something >that wasn't broken, or SCO for deciding that they knew the 'right' way >to do things -- thereby creating Pseudnix (I love that word). Or how about instead of silently truncating a file name > 14 characters, giving you a nice big fat error in the middle of a make or something until you clear a flag? Example: Try compiling cnews and create the subst file for spacefor. Blows up everytime! -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
sef@kithrup.COM (Sean Eric Fagan) (12/04/90)
In article <2349@cdin-1.UUCP> fred@cdin-1.UUCP (Fred Rump) writes: >Come on now. Of the sales going into the typical end-user shop how many do you >think can or will install news themselves? Well... the reason it (cnews) couldn't work can quite easily be run into by a normal user. Anyone who plays with the .maildelivery stuff, and has any reasonably complex program as the receiving end of the pipe can run into this mess. I ran into it with cnews, because I'm getting my feed via email. >Any site that is at that level should have no trouble at all with the >idiosyncracies of a relaxed SCO UNIX. Ha! It took me a *half-hour* to figure out what was going on! I know, I know, a half-hour isn't long. But most people aren't going to know this product as well as I do, and could easily spend a couple of days trying to figure out what was going on. >I don't still don't think it makes a hell of a lot of difference to 90% of the >sites out there. The problem is that ODT is being targeted as a single-user system. Single user systems generally don't *need* the stuff C2 offers. All it does is slow things down, complicate them, and make things break. (Note that adding networking is a good way to make your machine easy to break in, whether it's C2 or not...) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
woods@eci386.uucp (Greg A. Woods) (12/05/90)
In article <1990Dec03.090337.1142@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > Before you ditch SCO, please let me urge you to consider getting 3.2v2. > It's not perfect (nothing is), but it's a lot better than 3.2.0. I'm > running it at home, for example, which I wouldn't do if I didn't think it > was worth it (I'd run xenix instead, which I did for quite a while). Hmm... Funny how other vendors were able to take 3.2 and get it running reasonably well, even those with relatively little UNIX experience. Sure they took a few revisions before it was working well, but at least the first release didn't scare everyone silly! However, SCO, after having been in the UNIX-clone market for such a long time, take what I hope was a recent SysVr3.2 tape from AT&T, and manage to munge it up so much that people (including me) have been complaining since it was released. On top of that, we have people (from SCO) telling us SCOr3.2v0 is broke, and before you ditch SCO, please try SCOr3.2v2! I can't believe anyone would rush a product (not that being many months behind everyone other release of 3.2 can be construed as rushing) as important as this in such a way that Quality Control would go to the wind and they'd admit it took 2 revisions before it was worth anything! Personally, I'll stay with the faction that won't even consider running SCO-UNIX until the C2 security stuff is a complete option, and the SCO-3.2-generic is just as generic as all the rest. Regardless of what other features and mis-features are in SCOr3.2v2, I'll "suffer" with some other SysVr3.2/386. I don't want anything to do with C2 security unless it's a requirement of the client, and then probably only if they are big and important enough to make it an un-equivocal and outright mandatory requirement! Meanwhile, I'll probably be running "generic" SysVr4.0/386 long before SCO get their 3.2 sorted out! Some people already are running 4.0. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA "Political speech and writing are largely the defense of the indefensible"-ORWELL
richard@pegasus.com (Richard Foulk) (12/05/90)
> > Both SCO Xenix and SCO UNIX have *always* used /usr/spool/mail. >Sun and many BSD-based systems have followed that same convention. Perhaps >once Intel, ATT, ISC and SCO get together on the next UNIX 386 binary >standard they will clear up these and other subtle differences. It appears that V.4 will be go a long way to creating a more unified Unix. It introduces many changes, but it has a lot of momentum. And because it takes a great deal of work to bring up a new port the first round or two of releases will probably be fairly generic, the vendors not having enough time to mix in their own pet features. -- Richard Foulk richard@pegasus.com
mju@mudos.ann-arbor.mi.us (Marc Unangst) (12/05/90)
jdeitch@jadpc.cts.com (Jim Deitch) writes: > Or how about instead of silently truncating a file name > 14 > characters, giving you a nice big fat error in the middle of a make or > something until you clear a flag? Example: Try compiling cnews and > create the subst file for spacefor. Blows up everytime! Well, this "feature", at least, is pretty easy to fix. Go to /etc/conf/cf.d and run configure. Choose "Disk and Filesystem Parameters" (option #3, I think), and change the "ETRUNCATE" (or whatever it's called...The one about POSIX filename truncation) from the default value of "0" to "1". Relink, reboot, and viola, you have regular UNIX behavior for long filenames. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/06/90)
In article <1990Dec3.044437.21678@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: | You have obviously not used Shell Layers. If you use shell layers and create | a sub-shell and then execute 'stty intr \^c' it kills the shell. If you | forget that '^' is a synonym for ';' in SH, and you execute 'stty intr ^c' If you forget that you will be ahead of the game. ^ is an archaic form of pipe (as |) not ';'. Don't know about the rest of the stuff you said... -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
chip@tct.uucp (Chip Salzenberg) (12/07/90)
According to jdeitch@jadpc.cts.com (Jim Deitch): >Or how about instead of silently truncating a file name > 14 >characters, giving you a nice big fat error in the middle of a make or >something until you clear a flag? Example: Try compiling cnews and >create the subst file for spacefor. Blows up everytime! Dispite my low general opinion of SCO UNIX, this feature I like. I don't know about anyone else, but to me, if a shell executes the command "cat foobarbazxyzzy >foobarbazxyzzy2" and, in the process, silently truncates "foobarbazxyzzy", that's a bug. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I'm really sorry I feel this need to insult some people..." -- John F. Haugh II (He thinks HE'S sorry?)
aris@tabbs.UUCP (Aris Stathakis) (12/07/90)
In <275A9A50.3F3F@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to allbery@ncoast.ORG (Brandon S. Allbery KB8JRR): >>Not this time; SCO Pseudnix is getting bashed by more people than just a few >>Usenetters. SCO will get a clue *or* the same thing will happen to them as >>happened to IBM in the PC market: they will be bought only by hard-cores >>(like Chip is stuck with) while the rest of the market switches to something >>else. >An eloquent description of my current situation, and my expectations. >Wake up, SCO, and smell the coffee. We developers don't like SCO >UNIX-flavored C2 Operating System. When we are given the chance, >we'll buy something else. How long can you last without third-party >development? Ya, I don't like it either, but I can live with it. If we like it or not, we're going to have to live with a more secure UNIX. End users will be demanding it, and we'll have to provide it. Maybe not now, but 2 years down the line I think all UNIX systems will have a C2 or better security rating. Aris -- Aris Stathakis | Bang: ..!uunet!ddsw1!olsa99!tabbs!aris or aris@tabbs.UUCP - - - Never let your schooling interfere with your education. -
jfh@rpp386.cactus.org (John F Haugh II) (12/07/90)
In article <275E9FD4.377B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >Dispite my low general opinion of SCO UNIX, this feature I like. > >I don't know about anyone else, but to me, if a shell executes the >command "cat foobarbazxyzzy >foobarbazxyzzy2" and, in the process, >silently truncates "foobarbazxyzzy", that's a bug. it is a POSIX invention. i tend to agree that it is a "good idea", except that noone prior to 1003.1 had ever heard of "_POSIX_NO_TRUNC". this is definitely one of those features that should be "off" by default for AT&T filesystems, given the historical behavior. >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> > "Hi, I'm Chip Salzenberg and I'm a flaming idiot." > -- Chip Salzenborg nice .signature. you should keep this one for a while. ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
gorpong@ping.uucp (Gordon C. Galligher) (12/07/90)
In article <2491@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <1990Dec3.044437.21678@ping.uucp> gorpong@ping.uucp (ME) writes: > >| You have obviously not used Shell Layers. If you use shell layers and create >| a sub-shell and then execute 'stty intr \^c' it kills the shell. If you >| forget that '^' is a synonym for ';' in SH, and you execute 'stty intr ^c' > > If you forget that you will be ahead of the game. ^ is an archaic form >of pipe (as |) not ';'. Yea, it would be a good idea to forget that! :-) The fact still remains that if you use a blind 'stty intr' in a shell layer, you will reboot your machine. -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 gorpong@ping.chi.il.us gorpong%ping@uu.psi.com ...!uu.psi.com!ping!gorpong
rhealey@digibd.com (Rob Healey) (12/08/90)
In article <1990Dec3.044437.21678@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: >You have obviously not used Shell Layers. If you use shell layers and create >a sub-shell and then execute 'stty intr \^c' it kills the shell. If you >forget that '^' is a synonym for ';' in SH, and you execute 'stty intr ^c' >it REBOOTS THE MACHINE! Shell: /bin/sh Machine: NEC Powermate 386/20 4M memory. OS: SCO UNIX 3.2v2.0 I just did EXACTLY what Mr. Galligher suggested above and got nothing more than file not found because I didn't have a program called c in my path. I would say something in Mr. Galligher's setup is messed up, not shell layers or SCO UNIX per say. Maybe some more research should have been done before declaring SCO UNIX guilty... As an aside, I prefer POSIX job control under ksh88 to sh under shl but both work JUST FINE on my box. -Rob Speaking for self, not company.
rhealey@digibd.com (Rob Healey) (12/08/90)
In article <1990Dec3.050103.21819@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: >In article <1990Nov29.205938.3671@digibd.com> rhealey@digibd.com (Rob Healey) writes: >Have you used the crontab of SCO's unix? Have you used the 'df' program of >SCO's unix? Have you used the su of SCO's unix? All of these things are >not 'standard' UNIX, even with C2 security relaxed. You cannot 'su' to >root (or anyone else) unless you mess with the tcb/auth/crap files manually. >If you finally are successful in su'ing to root, you are really NOT root. >You cannot do things like change user's passwords (unless your LOGIN-ID has >a special thing set up on tcb/auth/crap, and then you can be the normal user >and STILL change other's passwords). If you 'su' to another user, you cannot >use 'crontab' which breaks things like: su uucp -c 'crontab /tmp/crontab'. >This is all things which are done in a user's point of view (yes, users DO >use the 'su' command, well, er, they DID before SCO "unix" came out...). > 1) The output of df and df -t on my SCO UNIX 3.2v2.0 EXACTLY matches the format of the df and df -t commands on an AT&T WGS running 3.2 5 feet away. These are the only two options I use. Also, the output of df /usr/lib matched as well. So, I don't see what the problem is. 2) Crontab and su do differ due to security. I'm not sure I'd want su uucp -c 'crontab /tmp/crontab' to work but I usually like to mess with crontabs directly. su to root can be granted via sysadmsh but I use a different program anyhoo and execsuid is all an authorized user needs. We don't have users using su to get things done, we do it a different way but that's a matter of administration... 3) As far as passwd goes, take away auth privledge with sysadmsh or edit /etc/auth/system/default and /etc/auth/subsystem/auth manually. The user can still change thier own password but not everyone else's. It does work, I tried it just now. The admin's like the fact that they don't have to su in order to change a password that someone forgot. By the way, by setting up /etc/default/{goodpw,passwd} properly you CAN make passwords as strict or as loose as you want. sysadmsh can be used to turn off password ageing as well for all users or just select users. >You may say that this is the security thing; well, yes it is. The problem >is, SCO has made the security TOO much a part of the entire operating >system. Merely 'relax'ing security in the sysadmsh is not enough. Too >many programs expect it to be running. It is almost as bad as Sun's >brain-damaged 386i line which forced its users to use YP, you could not >even send MAIL without having YP running, but I digress. :-) > It's a matter of how much time you can spend learning the system. We do fine but we had to take some time to learn it. Since alot of our business is SCO UNIX and Xenix it was worth our time to learn it. My point is that SCO UNIX differs in system administration and in some features advanced users would use if their shop doesn't provide other means; su and crontab. It's different but not necessarily evil or bad. Some of the SCO extentions are DAMN useful, others are a pain. You're waiting for SVR4, it'll be a MAJOR change from what you're used to and there is ALOT of new things to learn for system admin's and advanced users. If you think sysadmsh was "fun", wait till you see R4's equiv! Filesystem reorganization will be another fun change! And you can FORGET about online man pages... You also get the joys of following symlinks to symlinks to symlinks to ... SCO UNIX 3.2v2.0 is a useful UNIX system if you learn how security works. If you can't take the time to learn it, choose one of the other raw UNIX 3.2 systems. If you're comming up from Xenix, SCO UNIX softens the blow a bit. I think SCO UNIX's pluses outway the minus of the security system. I haven't seen much bashing not related to security, that seems to indicate to me that that's the main problem. The security can be tamed and the added value tools are useful for cross development. To each his own I guess... I just wanted to point out that there ARE sites that are using SCO UNIX and doing just fine. The security boogie man has more bark than bite. -Rob
rhealey@digibd.com (Rob Healey) (12/08/90)
In article <1990Dec04.003651.13014@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: >Or how about instead of silently truncating a file name > 14 >characters, giving you a nice big fat error in the middle of a make or >something until you clear a flag? Example: Try compiling cnews and >create the subst file for spacefor. Blows up everytime! > That's POSIX conformance fault not SCO specifically. cd to /etc/conf/cf.d, run configure, select menu 3, and set the ETRUNC parameter to 1. Quit configure, type link_unix, install the new kernel and reboot. The default behaviours on SCO UNIX are POSIX conformance rather than Xenix/ATT3.2UNIX conformance, where they collide, like ETRUNC, POSIX wins... There is some other POSIX stuff you can turn off but I'll leave that as an exercise to the reader. Tip: Read the System Administrator's Guide cover to cover, it'll save you some time in the long run. Next SCO UNIX complaint that can be solved by carefully reading the manuals or release notes please? B^). -Rob p.s. Ya, ya, ya, I know reading manuals is for whimps but sometimes it really DOES help.
vjs@calcite.UUCP (Vernon Schryver) (12/09/90)
In article <1990Dec1.225346.16828@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: > ... > * uucp --- everyone else is running HoneyDanber or at least SVR2 UUCP, which > gets 8-character UUCP names right.... There were 8 character hostname problems in SVR3.0 HDB UUCP on the 3B2 flavor tapes. I recall fixing one or two in my daytime job. I don't remember if they were fixed in SVR3.2, or if they were not and I had to finger it out. Things would work in one direction but not the other. Vernon Schryver, vjs@calcite.uucp
sef@kithrup.COM (Sean Eric Fagan) (12/09/90)
In article <2341@tabbs.UUCP> aris@tabbs.UUCP (Aris Stathakis) writes: >End users will be >demanding it, and we'll have to provide it. Uhm, I'm an end user, and I'm certainly not demanding it. What makes you think that SCO's C2 stuff makes it more secure? As far as I can tell, the stuff that helps the security is the password stuff: it checks for certain obvious passwords, will tell you if your password is a "good" one or not, and can be set to expire passwords. (I don't know about the latter one, actually. There *are* certain passwords you want to change regularly [such as root, for example], but if you expire passwords and force users to change their passwords on a regular basis, they're likely to just switch between two passwords.) The fact that it can take a longer string than 8 characters is also good. The luid stuff is mostly for accounting; I can come up with some circumstances where it would prevent some things from happening, but the bother is far more than it's worth. (Try playing with a pseudo-user's crontab entry, for example. Unless you want to futz with sending the appropriate signals and stuff to cron, you *can't*.) I know of nobody who ever enables the auditing (and I end up exchanging email with a *lot* of SCO users). It eats up too much disk space. >Maybe not now, but 2 years >down the line I think all UNIX systems will have a C2 or better >security rating. SCO doesn't have any rating at all for their UNIX. Not C2, not B, not even D1. Other people have explained why this is so, so I won't. The implementation of C2 that SCO went with *sucks*. In my other life, I officially endorse C2. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
gorpong@ping.uucp (Gordon C. Galligher) (12/09/90)
In article <1990Dec07.201729.29771@digibd.com> rhealey@digibd.com (Rob Healey) writes: >In article <1990Dec3.044437.21678@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: >>You have obviously not used Shell Layers. If you use shell layers and create >>a sub-shell and then execute 'stty intr \^c' it kills the shell. If you >>forget that '^' is a synonym for ';' in SH, and you execute 'stty intr ^c' >>it REBOOTS THE MACHINE! > > Shell: /bin/sh > Machine: NEC Powermate 386/20 4M memory. > OS: SCO UNIX 3.2v2.0 ^^^^ > > I just did EXACTLY what Mr. Galligher suggested above and got > nothing more than file not found because I didn't have a > program called c in my path. I would say something in Mr. > Galligher's setup is messed up, not shell layers or SCO UNIX per say. As someone already pointed out, this bug was fixed in ODT and/or SCO 3.2.2, whereas I am running 3.2.0. I did NOT make this clear, and this could lead to some confusion. If you get to a system with 3.2.0 and do what I said, you will most assuredly reboot your machine. I have mkdev shl no less than five times, and nothing changes. I also do 'tty' and it tells me 'not a tty.' > Maybe some more research should have been done before declaring > SCO UNIX guilty... As an aside, I prefer POSIX job control > under ksh88 to sh under shl but both work JUST FINE on my > box. The version I have does NOT have job control, therefore shl is the only thing I have. Granted, I should have made it more clear that I was running 3.2.0, but assuming that 3.2.2 is the ONLY unix SCO distributed is just plain wrong. -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 gorpong@ping.chi.il.us gorpong%ping@uu.psi.com ...!uu.psi.com!ping!gorpong
richard@pegasus.com (Richard Foulk) (12/09/90)
> You're waiting for SVR4, it'll be a MAJOR change from what you're > used to and there is ALOT of new things to learn for system admin's > and advanced users. If you think sysadmsh was "fun", wait till you > see R4's equiv! Filesystem reorganization will be another fun change! Symlinks make the reorganization a non-issue. -- Richard Foulk richard@pegasus.com
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/09/90)
In article <1990Dec7.155921.14639@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: | > If you forget that you will be ahead of the game. ^ is an archaic form | >of pipe (as |) not ';'. | | Yea, it would be a good idea to forget that! :-) The fact still remains that | if you use a blind 'stty intr' in a shell layer, you will reboot your | machine. I did not intend my correction to imply that the effect was not as Gordon said, and rebooting the machine is a major problem. I simply wanted to correct the analysis of the path between the input and the boot via ^. Hope that didn't confuse anyone. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/09/90)
In article <2341@tabbs.UUCP> aris@tabbs.UUCP (Aris Stathakis) writes: | Ya, I don't like it either, but I can live with it. If we like it or not, | we're going to have to live with a more secure UNIX. End users will be | demanding it, and we'll have to provide it. Maybe not now, but 2 years | down the line I think all UNIX systems will have a C2 or better | security rating. Since the average installation has neither a requirement (as in government) nor a desire for C2, I wouldn't bet the future of my company on it. The is a definite desire for greater security, but C2 is only one set of solutions to the problems. The problems are real, but the market will not choose high overhead solutions while alternatives are possible. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
jdeitch@jadpc.cts.com (Jim Deitch) (12/10/90)
In article <1990Dec08.140730.9747@digibd.com> rhealey@digibd.com (Rob Healey) writes: >In article <1990Dec04.003651.13014@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: >>Or how about instead of silently truncating a file name > 14 >>characters, giving you a nice big fat error in the middle of a make or >>something until you clear a flag? Example: Try compiling cnews and >>create the subst file for spacefor. Blows up everytime! >> > That's POSIX conformance fault not SCO specifically. cd to > /etc/conf/cf.d, run configure, select menu 3, and set the > ETRUNC parameter to 1. Quit configure, type link_unix, install > the new kernel and reboot. The default behaviours on SCO UNIX > are POSIX conformance rather than Xenix/ATT3.2UNIX conformance, > where they collide, like ETRUNC, POSIX wins... There is some > other POSIX stuff you can turn off but I'll leave that as an > exercise to the reader. Tip: Read the System Administrator's > Guide cover to cover, it'll save you some time in the long run. > > Next SCO UNIX complaint that can be solved by carefully reading > the manuals or release notes please? B^). > > -Rob >p.s. > Ya, ya, ya, I know reading manuals is for whimps but sometimes > it really DOES help. That isn't what I was complaining about. I was complaining that by default any other unix truncates. If SCO is shipping unix why not set the flag off by default? That way you are doing what the rest of the known universe expects. -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
woods@eci386.uucp (Greg A. Woods) (12/10/90)
In article <1990Dec5.005522.27397@pegasus.com> richard@pegasus.com (Richard Foulk) writes: > It appears that V.4 will be go a long way to creating a more unified Unix. > It introduces many changes, but it has a lot of momentum. Though I've never had a problem with the multipicity of UNIX variants (writing modern, portable, applications is easy, just so long as you don't restrict yourself to some silly subset, such as V7), I also feel SysVr4 will bring together (unify) UNIX users. As for changes, progress is impossible without change. > And because it takes a great deal of work to bring up a new port the > first round or two of releases will probably be fairly generic, the > vendors not having enough time to mix in their own pet features. From what I've seen, SysVr4 will significantly reduces the amount of effort required to port it to new architectures. Regardless, I do hope it takes some vendors a great deal of time (hopefully infinity) to introduce their own pet features. SysVr4 is "standard"; let's leave it that way! (I.e. if SCO do introduce SysVr4, and it includes "custom", I'll puke!) -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
jfh@rpp386.cactus.org (John F Haugh II) (12/10/90)
In article <2545@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > Since the average installation has neither a requirement (as in >government) nor a desire for C2, I wouldn't bet the future of my company >on it. The is a definite desire for greater security, but C2 is only one >set of solutions to the problems. Many of the features in the C2/B1 area are highly desireable to commercial installations. MAC alone would make many managers feel better knowing that the level "employee" is dominated by the level "manager" and that their personnel files are safer. > The problems are real, but the market will not choose high overhead >solutions while alternatives are possible. Correct - it is the bizarre, value-less restrictions which are being enforced here that people are objecting to. AIX v3.1 was "designed to meet" C2, yet it's "su" and "crontab" commands have none of the value-less restrictions you see with SCO UNIX. I wrote someone a note quoting parts from the C2 criteria and said "Where does it say you have to be a pain in the ass?". That sums it up perfectly. Shameless-plug time, but the shadow login package which I've been posting parts of gives most of the features people really want - secure passwords, login restrictions, nice password expiration, etc., but fits right on top of a vanilla UNIX SVRx implementation. If I could just get someone to send me a 386 with SCO UNIX loaded on it, I might be pursuaded to port the code to that environment. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
sef@kithrup.COM (Sean Eric Fagan) (12/10/90)
In article <1990Dec9.094337.7511@ping.uucp> gorpong@ping.uucp (Gordon C. Galligher) writes: >As someone already pointed out, this bug was fixed in ODT and/or SCO 3.2.2, >whereas I am running 3.2.0. I did NOT make this clear, and this could >lead to some confusion. If you get to a system with 3.2.0 and do what >I said, you will most assuredly reboot your machine. But you said that SCO never acknowledged this bug. I think fixing it is a pretty good acknowledgement of it. I urge you to upgrade. It's worth it. >Granted, I should have made it more clear that I was >running 3.2.0, but assuming that 3.2.2 is the ONLY unix SCO distributed >is just plain wrong. Perhaps you should play with the latest version of a product before you accuse a company of not fixing bugs. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/10/90)
In article <1990Dec09.185842.13158@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: >That isn't what I was complaining about. I was complaining that by >default any other unix truncates. If SCO is shipping unix why not set >the flag off by default? That way you are doing what the rest of the known >universe expects. I don't know why it's not shipped with truncating as default. I think it was due to something about meeting FIPS requirements. BSD does not truncate. Granted, it's a much larger size to deal with, but it doesn't truncate. Try creating a filename with 257 characters in its name: you'll get ENAMETOOLONG. If you don't like it, blame CSRG, who convinced the FIPS people that this action should be a requirement in all government POSIX bids. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
tim@delluk.uucp (Tim Wright) (12/10/90)
In <1990Dec07.214859.641@digibd.com> rhealey@digibd.com (Rob Healey) writes: ... > > You're waiting for SVR4, it'll be a MAJOR change from what you're > used to and there is ALOT of new things to learn for system admin's > and advanced users. If you think sysadmsh was "fun", wait till you > see R4's equiv! Filesystem reorganization will be another fun change! > And you can FORGET about online man pages... You also get the > joys of following symlinks to symlinks to symlinks to ... The AT&T FACE (Framed Access Command Environment) seems to make a quite decent SysAdmin interface - what's your problem with it ? If you want to do things by hand, there's still nothing to stop you. Why can you forget about online man pages ? That is vendor dependent, not OS release dependent. As a counter-example, Dell ship full online man pages. Finally, as has already been pointed out, the filesystem reorganisation can largely be ignored due to symbolic links. The reorganisation was not done just to be awkward. It is far better suited to running in a networked environment and allows for such interesting features as a read-only root filesystem. Where do you get to follow symlinks to symlinks ... I don't think the base system has any double symlinks (somebody will doubtless correct me), and if you're stupid enough to create lots yourself ... :-) Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
bill@camco.Celestial.COM (Bill Campbell) (12/11/90)
In <275A9A50.3F3F@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to allbery@ncoast.ORG (Brandon S. Allbery KB8JRR): >>Not this time; SCO Pseudnix is getting bashed by more people than just a few >>Usenetters. SCO will get a clue *or* the same thing will happen to them as >>happened to IBM in the PC market: they will be bought only by hard-cores >>(like Chip is stuck with) while the rest of the market switches to something >>else. >An eloquent description of my current situation, and my expectations. >Wake up, SCO, and smell the coffee. We developers don't like SCO >UNIX-flavored C2 Operating System. When we are given the chance, >we'll buy something else. How long can you last without third-party >development? >-- >Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> > "I'm really sorry I feel this need to insult some people..." > -- John F. Haugh II (He thinks HE'S sorry?) I agree totally whih Chip here. There are a number of good things I have heard about SCO UNIX, and two consistently abominable, C2 security and outdated MMDF. I've been using Xenix is its various flavors since 1982 and like it a lot. One of the basic design goals under Xenix has been compatibility with older versions which means they cannot muck with directory locations and options to commands the way AT&T has. This has meant that I didn't have to go back and change all my old scripts/programs with each new release of Xenix because some well-meaning idiot changed 'grep -y' to 'grep -i' because it made more sense that way (non of it makes sense without TFM anyway). I would love to see SCO UNIX available, not with 'relaxed' C2 security, but with NO C2 security. Shadow passwords are probably a good idea, but unnecessary if you use good passwords in the first place (not your spouse's name, birthday...). Most security problems are caused by lazy, incompetent system administrators, not by the operating system. -- INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software UUCP: ...!thebes!camco!bill 6641 East Mercer Way uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591
guy@auspex.auspex.com (Guy Harris) (12/11/90)
>Or how about instead of silently truncating a file name > 14 >characters, giving you a nice big fat error in the middle of a make or >something until you clear a flag? "Good enough for government work". POSIX allows either behavior, but, as I remember from previous discussions of this topic, the FIPS ((US) Federal Information Processing Standard) based on POSIX 1003.1 requires the ENAMETOOLONG error for this. The most you could conceivably blame SCO for is not having a switch that lets users who don't care about the FIPS select the traditional behavior (or for deciding not to blow off government business)....
drmorris@athena.mit.edu (David R Morrison) (12/11/90)
In article <1990Dec08.224008.829@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > The implementation of C2 that SCO went with *sucks*. I wrestled with SCO last summer, and what amused me most was that they went to an extreme to make the machine (kernel/os) secure, and practicly ignored making a distributed system secure. Using NFS, by being root on my machine alone, I could access nearly anyone's files by frobbing my uid. One of my jobs was to set up printing; their solution to distributed printing (I had a FAX, straight from support) was along the lines of becoming user 'lp' on the print server, and doing an rsh to submit the job as 'lp' on the print server. It wasn't difficult to forge becoming 'lp' there. This is a C2 secure system? Dave Morrison
vic@grep.co.uk (Victor Gavin) (12/11/90)
In article <1990Dec9.143700.9682@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >> see R4's equiv! Filesystem reorganization will be another fun change! > >Symlinks make the reorganization a non-issue. As I understand it, AT&T are using SUN's hashed up multiple-system-f*cked-up-symbolic-everything filesystem. Have you ever tried to access it over a network. None of the symlinks works out right (This was from an HP 9000 to a SUN386i). Now take a look at HP's Context Dependent Files. Much cleaner, easier to maintain, aestetically please. Also now part of OSF. Coming to a system near you Real Soon Now. vic
pizzi@esacs.UUCP (Riccardo Pizzi) (12/11/90)
In article <531@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes: >I would love to see SCO UNIX available, not with 'relaxed' C2 >security, but with NO C2 security. Shadow passwords are probably >a good idea, but unnecessary if you use good passwords in the >first place (not your spouse's name, birthday...). Most security >problems are caused by lazy, incompetent system administrators, >not by the operating system. I completely agree with you. The incompetence of users standing at the top of the list. How many machines have forgotten logins without passowrd around the world? I'm sure there are a *lot*. Rick -- Riccardo Pizzi @ ESA Software, Rimini, ITALY e-mail: pizzi%esacs@relay.EU.net -or- root@xtc.sublink.org Public Access Unix @ +39-541-27858 (Telebit) << Object Oriented is an Opaque Disease >>
jfh@rpp386.cactus.org (John F Haugh II) (12/11/90)
In article <DRMORRIS.90Dec10185729@copilot.mit.edu> drmorris@athena.mit.edu (David R Morrison) writes: >I wrestled with SCO last summer, and what amused me most was that they >went to an extreme to make the machine (kernel/os) secure, and practicly >ignored making a distributed system secure. Technically speaking, there is no such thing as a secure distributed system. The Orange Book does not address network O/S's and once you connect your machine to another, all bets were off. >This is a C2 secure system? No. It's a bunch of stuff someone decided to market as a C2 system. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
jfh@rpp386.cactus.org (John F Haugh II) (12/11/90)
In article <531@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes: >I would love to see SCO UNIX available, not with 'relaxed' C2 >security, but with NO C2 security. Shadow passwords are probably >a good idea, but unnecessary if you use good passwords in the >first place (not your spouse's name, birthday...). Most security >problems are caused by lazy, incompetent system administrators, >not by the operating system. Anyone how believes this has never read Appendices C and F out of the DoD "Password Management Guidelines". The difference between a system with shadowed passwords and non-shadowed passwords being cracked is many orders of magnitude. Think for a moment about a college network of say, 100 IBM S/6000's. Using whatever benchmark results we have today, that is about 2,500 MIPS. If a system in the 3 - 5 MIPS range can produce 1,000 UNIX style encryptions per second, we should be able to get over 500,000 encryptions per second on our little network. Now have a shadow password system that turns your account off after 100 failures. If you reenable the account once per day (after a long night of hacking ;-), you get 864 seconds per encryption, or a difference of 432,000,000 to 1. That's almost 9 orders of magnitude. Which means that =your= password must come from a set which is almost 1,000,000,000 times larger than mine - just to be just as secure. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (12/12/90)
In article <4754@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Or how about instead of silently truncating a file name > 14 >>characters .... >The most you could conceivably blame SCO for is not having a switch that >lets users who don't care about the FIPS select the traditional behavior >(or for deciding not to blow off government business).... 3.2.0 does not have a switch, but a semi-official patch works well: RossO> When an attempt is made to create a file whose name is longer RossO> than 14 characters, SCO UNIX System V/386 returns an error, and RossO> the file is not created. This behavior was added for compliance RossO> with POSIX FIPS. It also breaks many programs which expect RossO> filenames to be silently truncated. Below is a patch to the UNIX RossO> kernel so that long filenames will be truncated rather than RossO> returning an error. Bring your system into system maintenance RossO> mode, and enter these commands: RossO> RossO> # /etc/_fst -w /etc/conf/pack.d/s5/Driver.o RossO> * $x RossO> * s5namei+0xab?w 0x0feb RossO> * $q RossO> RossO> # /etc/_fst -w /etc/conf/pack.d/xx/Driver.o RossO> * $x RossO> * xxnamei+0xa6?w 0x0feb RossO> * $q RossO> RossO> Next, relink your kernal by typing /etc/conf/cf.d/link_unix, then RossO> reboot your system. If you ever reinstall the link package you RossO> will need to repeat this procedure. RossO> RossO> Ross Oliver RossO> Technical Support RossO> The Santa Cruz Operation, Inc. 3.2.1 and beyond has a *switch* in the /etc/conf/cf.d/configure procedure. ---------------------------------------------------------------------------- Warren Tucker emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "I was 35 years old before I knew a pie was meant to be eaten." - Moe Howard
wengland@stephsf.stephsf.com (Bill England) (12/12/90)
>* grep --- why should I have to remember that, ouyt of all the System V > machines in the office, only the SCO Pseudnix machine uses "-y" to do case- > ignored searches? All the others use "-i". >-- >Me: Brandon S. Allbery Internet: allbery@NCoast.ORG Un huh. YOU did try "grep -i" ???? It does work but, the manual page forgets to mention it :-) I was supprised because I've been 'grep -i'ing for the past year and a half and never noticed that it was not in the manual page. I kind of like the 'C2' software options. Most of these are burried in user level programs and not the kernal however. I believe that the only significant _kernal_ mod is the addition of an additional uid (luid?). In my mind this makes SCO's Unix kernal not significantly different from other Unix's to worry about (let alone flame over.) --
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/12/90)
In article <531@camco.Celestial.COM> bill@camco.Celestial.COM (Bill Campbell) writes: | Shadow passwords are probably | a good idea, but unnecessary if you use good passwords in the | first place (not your spouse's name, birthday...). Most security | problems are caused by lazy, incompetent system administrators, | not by the operating system. But if someone can get your encrypted password they can get your real password, secure or not. It will take longer, but there are enough CPU cycles floating around to do a brute force crack in a number of places, on supercomputers or just a gaggle of Suns working over the weekend. If they can't get the crypted password they have to crack it on your machine by trying one at a time. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/12/90)
In article <4754@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: | The most you could conceivably blame SCO for is not having a switch that | lets users who don't care about the FIPS select the traditional behavior | (or for deciding not to blow off government business).... If you mean what I think you do, you can throw that switch, they did provide it. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
rcd@ico.isc.com (Dick Dunn) (12/12/90)
jfh@rpp386.cactus.org (John F Haugh II) writes: ... > Many of the features in the C2/B1 area are highly desireable to > commercial installations... hype. I don't know of *any*thing in C2/B1, that's not in "traditional" UNIX, that commercial installations would want, let alone need. >...MAC alone would make many managers > feel better knowing that the level "employee" is dominated by > the level "manager" and that their personnel files are safer. off the wall. How many managers have you got, and how many employees? You want to make 10% of your people feel better at the expense of 90%? A manager stupid enough to keep personnel files unencrypted on a machine accessible to employees should be fired without hesitation; bag the C2. If you're going to talk about who "feels better" you ought to look at both sides. If you want to know whether a cattle prod is a pain in the ass, you'd better ask the owner of the ass as well as the owner of the prod. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
beattie@visenix.UUCP (Brian Beattie) (12/12/90)
In article <18804@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: -In article <DRMORRIS.90Dec10185729@copilot.mit.edu> drmorris@athena.mit.edu (David R Morrison) writes: ->I wrestled with SCO last summer, and what amused me most was that they ->went to an extreme to make the machine (kernel/os) secure, and practicly ->ignored making a distributed system secure. I read this as "making a delivered system secure". - -Technically speaking, there is no such thing as a secure distributed Bzzzzzzzt I'm sorry but that is not correct. :-) -system. The Orange Book does not address network O/S's and once you -connect your machine to another, all bets were off. It is The Red Book disscusses this issue. Although John is correct with respect to the Orange Book, in that if you have an ethernet or a modem or a pad or the like your system is outside the scope of the Orange Book. That is not to say that it is insecure, just that it does not meet the requirements of a TCB (Trusted Computing Base) as described in the Orange Book. - ->This is a C2 secure system? - -No. It's a bunch of stuff someone decided to market as a C2 system. And a pretty poor example of what can be done at that. --- -John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh -Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org -- It is easier to build a | Brian Beattie (703)471-7552 secure system than it is | 11525 Hickory Cluster, Reston, VA. 22090 to build a correct system.| M. Gasser | ...uunet!visenix!beattie
jfh@rpp386.cactus.org (John F Haugh II) (12/13/90)
In article <1990Dec12.085044.19965@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >hype. I don't know of *any*thing in C2/B1, that's not in "traditional" >UNIX, that commercial installations would want, let alone need. Object auditing, for starters. It lets you know who has access to what data and when they have accessed it. Mandatory Access Control for isolating information by employee level (employee, supervisor, manager, executive, etc.). Access Control Lists for fine granualarity access control to applications and data. Subject auditing (programs) for real time threat detection for commercial systems connected to outside networks. >off the wall. How many managers have you got, and how many employees? You >want to make 10% of your people feel better at the expense of 90%? A >manager stupid enough to keep personnel files unencrypted on a machine >accessible to employees should be fired without hesitation; bag the C2. UNIX standard encryption routines are so weak as to be laughable. The mere existence of a network connection makes most machines accessible to employees. Get a copy of Crypt Breakers Workbench and see just how secure that crypt command is. >If you're going to talk about who "feels better" you ought to look at both >sides. If you want to know whether a cattle prod is a pain in the ass, >you'd better ask the owner of the ass as well as the owner of the prod. Well, it might be nice of SCO would have actually implemented a real C2 system instead of the thing SecureWare gave them. Then you might get to see that C2/B1 is not the incredible pain in the ass you would like to believe it is. There is no need for any of the problems people are experiencing to occur on a C2 system. If you check the Orange Book you will find that many of the more troublesome features are B1 or higher requirements. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
luke@modus.sublink.ORG (Luciano Mannucci) (12/13/90)
In article <531@camco.Celestial.COM>, bill@camco.Celestial.COM (Bill Campbell) writes: > I would love to see SCO UNIX available, not with 'relaxed' C2 > security, but with NO C2 security. How true! I just lost my queryspace autorisation -for the user root :( - and am not able to restore it; nor manually, nor via sysadmsh! Nice feature, isn't it? Ah, good old xenix times! To know my free space amount, I have to mount my hard disk on my HP-UX filesystem! > Shadow passwords are probably > a good idea, but unnecessary if you use good passwords in the > first place (not your spouse's name, birthday...). Most security > problems are caused by lazy, incompetent system administrators, > not by the operating system. Yes I agree. My question is why wasting space (RAM and disk) for *security* improvements on a machine NOT NECESSARILY CONNECTED ELSEWHERE? Compaq computer corp. supplied me with a hardware key, and I think that's quite enough for me. luke. -- _ _ __ Via Aleardo Aleardi, 12 - 20154 Milano (Italy) | | | _ _| (__ PHONE : +39 2 3315328 FAX: +39 2 3315778 | | |(_)(_||_|___) Srl E-MAIL: luke@modus.sublink.ORG ______________________________ Software & Services for Advertising & Marketing
rhealey@digibd.com (Rob Healey) (12/13/90)
In article <1990Dec9.143700.9682@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >> You're waiting for SVR4, it'll be a MAJOR change from what you're >> used to and there is ALOT of new things to learn for system admin's >> and advanced users. If you think sysadmsh was "fun", wait till you >> see R4's equiv! Filesystem reorganization will be another fun change! > >Symlinks make the reorganization a non-issue. > >-- >Richard Foulk richard@pegasus.com Ummm, must be a definition of non-issue I've never heard before... I still have some nightmares of SunOS systems with the symlinks from hell... The file reorganization will break many a code that assumes the classic /,/bin,/etc,/usr/bin,/usr/lib,/usr/spool configuration. Making 1,000 symlinks will make things worse not better... -Rob
chip@tct.uucp (Chip Salzenberg) (12/13/90)
According to rhealey@digibd.com (Rob Healey):
> SCO UNIX 3.2v2.0 is a useful UNIX system if you learn how security works.
I know how it works.
That's why I don't like it.
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"What's that thing, when people die, they take apart the body to see why?"
-- St. Theresa of the Netjfh@rpp386.cactus.org (John F Haugh II) (12/13/90)
In article <876@visenix.UUCP> beattie@visenix.UUCP (Brian Beattie) writes: >In article <18804@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >-Technically speaking, there is no such thing as a secure distributed > >Bzzzzzzzt I'm sorry but that is not correct. :-) > >-system. The Orange Book does not address network O/S's and once you >-connect your machine to another, all bets were off. > >It is The Red Book disscusses this issue. > >Although John is correct with respect to the Orange Book, in that if >you have an ethernet or a modem or a pad or the like your system is >outside the scope of the Orange Book. That is not to say that it is >insecure, just that it does not meet the requirements of a TCB (Trusted >Computing Base) as described in the Orange Book. As far as I know, the NCSC has =never= formally evaluated a system using the Red Book. For network stuff I use the Red Book as I guide, but I don't believe that it is the authoritative answer on network security. At least, not until someone has a system rated using the criteria in there. I don't even know that anyone has ever submitted a configuration for evaluation according to the Red Book. I am sure someone will correct me if I am wrong, but none of the final evaluation reports I've read or seen listed refer to network systems or the Red Book. I am not convinced that there will ever be a heterogenous secure distributed system and I'm not so sure homogenous is going to happen any time soon. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
jfh@rpp386.cactus.org (John F Haugh II) (12/13/90)
In article <2766B8EB.3D7@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to rhealey@digibd.com (Rob Healey): >> SCO UNIX 3.2v2.0 is a useful UNIX system if you learn how security works. > >I know how it works. > >That's why I don't like it. Perhaps if more people (besides Dick Dunn ;-) would learn how security REALLY works, SCO would have to remove the stuff that they pretend is "security" and put in something else that is a tad more usable. I challenge anyone from either SCO or SecureWare to demonstrate that the more annoying features are implemented at the C2 level with the least amount of annoyance as permitted by the criteria for that level. You will find a lot of B1 and B2 features once you start looking real hard. Like, what's the deal with the "df" command, guys? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <1990Dec08.140730.9747@digibd.com> by rhealey@digibd.com (Rob Healey): +--------------- | In article <1990Dec04.003651.13014@jadpc.cts.com> jdeitch@jadpc.cts.com (Jim Deitch) writes: | >Or how about instead of silently truncating a file name > 14 | >characters, giving you a nice big fat error in the middle of a make or | >something until you clear a flag? Example: Try compiling cnews and | >create the subst file for spacefor. Blows up everytime! | > | That's POSIX conformance fault not SCO specifically. cd to +--------------- That isn't true, as far as I've been able to learn. I don't know if it's a lie or a misunderstanding on the part of someone at SCO, but it is incorrect. The POSIX filename truncation vs. error business is *optional* behavior intended to allow systems with hard filename length restrictions to still support a POSIX source code environment. It is *not* required, nor even desirable (from a POSIX compliance standpoint, that is), as far as I have been able to determine. I suspect that line is just SCO trying to justify managing to break "UNIX" in yet another way while managing to conform to all applicable standards. They excel at this, from my experience with SCO "UNIX". ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <4754@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | >Or how about instead of silently truncating a file name > 14 | >characters, giving you a nice big fat error in the middle of a make or | >something until you clear a flag? | | POSIX allows either behavior, but, as I remember from previous | discussions of this topic, the FIPS ((US) Federal Information Processing | Standard) based on POSIX 1003.1 requires the ENAMETOOLONG error for | this. +--------------- Remind me never to take a programming job that involves U.S. government work. Those cretins *would* do something stupid like this. Maybe they'll demand that people program in FORTRAN next. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <99@calcite.UUCP> by vjs@calcite.UUCP (Vernon Schryver): +--------------- | In article <1990Dec1.225346.16828@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: | > ... | > * uucp --- everyone else is running HoneyDanber or at least SVR2 UUCP, which | > gets 8-character UUCP names right.... | | There were 8 character hostname problems in SVR3.0 HDB UUCP on the 3B2 | flavor tapes. I recall fixing one or two in my daytime job. I don't +--------------- AT&T's UNIX releases for the 3B2 have been, er, strange. I've been helping a local company maintain 3B2's with WIN/3B on them. Ugh. In any case, I have used SVR2 UUCP (Plexus P/60) and HDB for SVr3.1 (Altos 1000); *neither* had any problems with 8-character host names in either direction. (I may be wrong about the SVR2 UUCP, it's been 3 1/2 years since I last touched it. But I work with the SVR3.1 machines daily, including UUCP.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <445@stephsf.stephsf.com> by wengland@stephsf.stephsf.com (Bill England): +--------------- | >* grep --- why should I have to remember that, ouyt of all the System V | > machines in the office, only the SCO Pseudnix machine uses "-y" to do case- | > ignored searches? All the others use "-i". | >-- | >Me: Brandon S. Allbery Internet: allbery@NCoast.ORG | | Un huh. YOU did try "grep -i" ???? +--------------- Maybe it's in the new 3.2.2 that will remain vaporware for us until our device drivers are ported to it. But I *did* try it, which is why the outburst: I got a usage message which didn't show "i" and *did* show "y". After which I consulted the manual and finished off my adding another line to the problems list I regularly feed to Altos in an attempt to get them to switch back to running Unix on their hardware. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <1990Dec12.192318.19658@digibd.com> by rhealey@digibd.com (Rob Healey): +--------------- | In article <1990Dec9.143700.9682@pegasus.com> richard@pegasus.com (Richard Foulk) writes: | >> You're waiting for SVR4, it'll be a MAJOR change from what you're | >> used to and there is ALOT of new things to learn for system admin's | >> and advanced users. If you think sysadmsh was "fun", wait till you | >> see R4's equiv! Filesystem reorganization will be another fun change! | > | >Symlinks make the reorganization a non-issue. | | I still have some nightmares of SunOS systems with the symlinks | from hell... The file reorganization will break many a code | that assumes the classic /,/bin,/etc,/usr/bin,/usr/lib,/usr/spool | configuration. Making 1,000 symlinks will make things worse | not better... +--------------- Files in strange places is a *minor* problem. Not only have I used SunOS 4.1 (not to mention DG/UX, which also has SVR4/SunOS filesystem layout), but after coping with another SCO "UNIX" difference from UNIX I'm used to files not being where I expect. You see, SCO hasn't figured out yet that /etc is for system maintenance commands; somehow, they usually end up in /bin, while basic system tools end up in /usr/bin. This results in hackery in SCO "UNIX" to make sure /usr is mounted in single-user mode (as we receive it, it's configured to create a separate /usr filesystem), since SCO decided not to fix the real problem but to hack around it instead.... ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <2341@tabbs.UUCP> by aris@tabbs.UUCP (Aris Stathakis): +--------------- | Ya, I don't like it either, but I can live with it. If we like it or not, | we're going to have to live with a more secure UNIX. End users will be | demanding it, and we'll have to provide it. Maybe not now, but 2 years | down the line I think all UNIX systems will have a C2 or better | security rating. +--------------- Beg pardon, but I just read an article recently (in VARBUSINESS) about how C2 may be great for the government, but its security features aren't the same as the security features wanted by most businesses. Consider that the Orange Book sets out a security scheme that is ultimately intended to block security leaks by highly-placed spies.... ...whereas if I wanted to make the SVR3.1 system at work secure from prying outsiders, I could do so without C2. Although I do admit that group vectors help a lot. But group vectors aren't the problem with C2. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/14/90)
As quoted from <1990Dec08.224008.829@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | The implementation of C2 that SCO went with *sucks*. | | In my other life, I officially endorse C2. +--------------- This may be one reason why SCO UNIX has problems... had you considered demonstrating to your bosses that (and why) their C2 product is going over like the proverbial lead balloon? ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
sef@kithrup.COM (Sean Eric Fagan) (12/15/90)
In article <1990Dec14.035940.28832@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >That isn't true, as far as I've been able to learn. I don't know if it's a >lie or a misunderstanding on the part of someone at SCO, but it is incorrect. > >The POSIX filename truncation vs. error business is *optional* behavior >intended to allow systems with hard filename length restrictions to still >support a POSIX source code environment. It is *not* required, nor even >desirable (from a POSIX compliance standpoint, that is), as far as I have been >able to determine. It *is* required by FIPS, which is a superset of POSIX. That is the only reason it's there. So the misunderstanding is on your part. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/15/90)
In article <1990Dec14.040211.29253@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >Remind me never to take a programming job that involves U.S. government work. >Those cretins *would* do something stupid like this. They adopted that option because the Berkeley folks pushed for it (according to McKusick). So "those cretins" refers to the folks at Berkeley; SCO went along with it, after the fact, because it was required for government work. And note that it is now possible to configure this off, so it behaves like a sane V7 filesystem (in that respect only). On the other hand, FIPS also requires job control (which *does* work in 3.2v2, and is quite nice), and I believe it also specifies the sticky-bit on directories thingy, which is also nice. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
richard@pegasus.com (Richard Foulk) (12/15/90)
>> >>Symlinks make the reorganization a non-issue. > >As I understand it, AT&T are using SUN's hashed up >multiple-system-f*cked-up-symbolic-everything filesystem. > >Have you ever tried to access it over a network. >None of the symlinks works out right (This was from an HP 9000 to a SUN386i). Works just fine for me. -- Richard Foulk richard@pegasus.com
wengland@stephsf.stephsf.com (Bill England) (12/16/90)
In article <1990Dec14.040922.29479@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: > >Maybe it's in the new 3.2.2 that will remain vaporware for us until our device >drivers are ported to it. But I *did* try it, which is why the outburst: I >got a usage message which didn't show "i" and *did* show "y". After which I > >++Brandon Sorry Brandon, I'm running SCO-ODT and grep -i works like it is supposed to. Some details; ---- release: 3.2 node name: stephsf version: 2 machine name: i386 time of crash: Sat Dec 15 12:09:06 1990 $ grep -? grep: illegal option -- ? Usage: grep -hblcnsvi [-e expr] [-f expr_file] pattern file . . . --- I've had this software since the begining of the year, actually Dec 89, as part of SCO's Developer program. The grep man page is incorrect however as it lists the y option and not the i option. If you have an SCO Sys V deviations list I would be interested in seeing it. Thanks, -- +- Bill England, wengland@stephsf.COM -----------------------------------+ | * * H -> He +24Mev | | * * * ... Oooo, we're having so much fun making itty bitty suns * | |__ * * ___________________________________________________________________|
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/16/90)
As quoted from <1990Dec15.021924.2866@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | In article <1990Dec14.035940.28832@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: | >That isn't true, as far as I've been able to learn. I don't know if it's a | | It *is* required by FIPS, which is a superset of POSIX. That is the only | reason it's there. +--------------- So I found out, later. Cf. my snide remark about the Federal Ignorant Programming Standard and FORTRAN. (I've not used Ada, but it has at least *some* redeeming qualities compared to FORTRAN, at least for the kind of programs I write.) If I didn't know better, I'd call that a cheap ploy to make System V undesireable for FIPS work.... ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/16/90)
As quoted from <1990Dec15.022225.2969@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | In article <1990Dec14.040211.29253@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: | >Those cretins *would* do something stupid like this. | | So "those cretins" refers to the folks at Berkeley; SCO went along with it, +--------------- Sorry, I meant the idiots who accepted that into FIPS, not SCO. +--------------- | On the other hand, FIPS also requires job control (which *does* work in | 3.2v2, and is quite nice), and I believe it also specifies the sticky-bit on | directories thingy, which is also nice. +--------------- Agreed as to the sticky bit. I still prefer multiple windows to job control, though. One question: are there any known bugs in 3.2.1 job control? I'm having one heck of a time trying to make a program to do job control "after the fact" (it's patterned after shl) because of background tty reads doing various unexpected things. Is it the job control, or is it just something I wasn't able to ferret out of the documentation that I'm missing? (And where can I find programmers' docs for job control?) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
evan@telly.on.ca (Evan Leibovitch) (12/17/90)
In article <18818@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >Perhaps if more people (besides Dick Dunn ;-) would learn how security >REALLY works, SCO would have to remove the stuff that they pretend is >"security" and put in something else that is a tad more usable. A client of mine, considering upgrading a large number of systems to either SCO Unix or Interactive, says he was told by none less than Larry Michaels that SCO UNIX (including the MPX version) would soon be made available without C2. Can anyone sweating in the SCO trenches confirm their boss's comment? Is this something really being readied, or was this "assurance" mere vapor-speak? -- Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504 Ididntdoit, nobodysawmedoit, youcantproveathing. - Bart
sef@kithrup.COM (Sean Eric Fagan) (12/17/90)
In article <1990Dec16.023519.9152@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >If I didn't know better, I'd call that a cheap ploy to make System V >undesireable for FIPS work.... Why not go with your instincts? 8-) Kirk stated (at a talk about the future of BSD [*not* the UseNIX one, this was at a bookstore when the BSD book came out]) that they (the Berkeley Folks) pushed for some of the options as FIPS requirements to get people to use "sane" operating systems... I won't repeate what my whispered comments were... 8-) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/17/90)
In article <1990Dec16.023934.9258@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >One question: are there any known bugs in 3.2.1 job control? Yep. It doesn't work. Period. For example, you can change the pgrp of a tty, but the ioctl will report failure. You cannot change it back to your pgrp id. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/19/90)
As quoted from <1990Dec17.064818.6437@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | For example, you can change the pgrp of a tty, but the ioctl will report | failure. You cannot change it back to your pgrp id. +--------------- Yeah, that sounds right. I wrote a program to do job control for a shell a' la shl, and backgrounding behaved strangely. Not that it matters, I should have MGR up and running by the end of the week. I *still* prefer windows to job control. (I just hope I can get patches out a little sooner than I did with the MMDF #43 patches....) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
ch@dce.ie (Charles Bryant) (12/19/90)
In article <1990Dec08.224008.829@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >The luid stuff is mostly for accounting; I can come up with some >circumstances where it would prevent some things from happening, but the >bother is far more than it's worth. (Try playing with a pseudo-user's >crontab entry, for example. Unless you want to futz with sending the >appropriate signals and stuff to cron, you *can't*.) While this is one reason I wrote oksetluid() (which forces the luid to change, overriding the "security" if necessary), it is not too difficult to get cron to reread the crontabs. Normally cron is started from /etc/rc. Instead, start it from a line in the inittab. Then when you change a crontab just kill cron and init will start another one. Of course cron orpans itself (nasty feature), so you need to write /etc/pause (not too difficult :-), and use the following in inittab: cron:2:respawn:/etc/startcron >/dev/console 2>&1 where startcron is: : use /bin/sh # Start cron by removing an old FIFO and starting cron itself. # We need this script because inittab commands are execed so there # can't be more than one shell command. # Aug 17 1990 rm -f /usr/lib/cron/FIFO trap "" 2 3 # Don't let console quit and intr affect cron. . /etc/TIMEZONE # Probably don't need /etc/cron # Cron forks into the background so this script waits forever; kill the # script when you kill cron, if you want to start a new cron. exec /etc/pause I must agree that the "C2 security" is a joke. In fact it probably reduces the security of the system as its so complicated its a lot easier to believe that a strang happening is a problem with the security system rather than a break-in attempt. -- Charles Bryant (ch@dce.ie) -- /usr/ch/.signature: Block device required
richard@pegasus.com (Richard Foulk) (12/19/90)
>+--------------- >| On the other hand, FIPS also requires job control (which *does* work in >| 3.2v2, and is quite nice), and I believe it also specifies the sticky-bit on >| directories thingy, which is also nice. >+--------------- > >Agreed as to the sticky bit. I still prefer multiple windows to job control, >though. Who said it was an either/or proposition? What's wrong with having both like god intended. -- Richard Foulk richard@pegasus.com
seanf@sco.COM (Sean Eric Fagan) (12/29/90)
In article <18809@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >UNIX standard encryption routines are so weak as to be laughable. >[...] >Get a copy of Crypt Breakers Workbench and see just how >secure that crypt command is. These are two different things. The crypt *command* is *not* DES, while the encrypt *routine* is. There is a big difference between breaking the command and breaking the routine. vi -x used to let you edit encrypted files; I don't know if anyone supports it anymore (there are, of course, problems sending such a vi out of the country, thanks to the DoC). If you've got a nice way to break DES, post it to the world... 8-) -- -----------------+ Sean Eric Fagan | "*Never* knock on Death's door: ring the bell and seanf@sco.COM | run away! Death hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.