chip@tct.uucp (Chip Salzenberg) (12/27/90)
According to annala@neuro.usc.edu (A J Annala): >In article <2777E87B.6392@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >>Well, of course it won't run VMS. VMS is coded in VAX assembler. > >My friends tell me most of VMS is coded in a DEC proprietary language >called BLISS. BLISS exists for PDP-11's, PDP-10's, and VAXen -- DEC >could have chosen to write a new BLISS compiler for the 80386 -- but >that is not what happened -- instead, DEC adopted SCO UNIX for their >new machine. Um, okay. I've also been informed by Thomas Breuel that significant portions of VMS are written in FORTRAN. So to port VMS to the 386, you'd have to translate all the assembler code, the BLISS language support and the FORTRAN language support to the 386. No small job, even for DEC. >Moreover, in the process, DEC abandoned it's own ULTRIX >(DEC proprietary version of UNIX) in order to adopt SCO UNIX. SCO UNIX has ready support for *multiprocessing* (SCO MPX). ULTRIX doesn't. I'll bet that this consideration was probably the most important one. This advantage is utterly unrelated to any security issues. (Also, ULTRIX hasn't yet been ported to the 386; such a port would likewise be no small job, though infinitely easier than VMS.) >Living within C2 guidelines is causing us no real grief. Congratulations. You're one of the few and fortunate. >What more do you want from SCO UNIX? I've enumerated the problems with C2 before. To repeat some of them: 1. User info is spread out. Besides /etc/passwd, you must have a file /tcb/files/auth/<first letter of user>/<user>. Some of the fields in the auth file duplicate fields in /etc/passwd. So forget using vi on /etc/passwd. 2. User and group identities determine privilege at the kernel level. For example, user "chip" may be able to run a setuid-root program, while user "steve" cannot. This is a maintenance nightmare. 3. The C2 security (as described in #2) can be "relaxed", but not disabled. That is, the default kernel permissions can be broadened from their fascist defaults, but the kernel is still a C2 kernel. So the administrative headaches are still there. 4. There are lots of "databases" in /etc/auth that figure in system security -- i.e. they get in the way. For example, to add a new shell type in /usr/lib/mkuser, it's necessary to edit the secure files database /etc/auth/system/files. When you add a new terminal, including a pty, it must be in /etc/auth/system/ttys. Etc. 4b. C2 breaks automated system administration scripts. Our application had a program to create a new user. That program doesn't work any more. Now users have to run the sysadmsh to create new users. We took great pains to have a consistent user interface in our system; the use of sysadmsh blows that strategy out of the water. Yes, we could write a new program using the new library routines. But why should we have to? Whatever happened to that watchword of Unix System V, "portability"? The addition of new ttys is another example. Each tty must be in the tty database before it can be used for logins. This "feature" breaks the installation scripts we used for our application. Yes, we know about /tcb/bin/ttys_update. But we object to the fact that we need to know about it and we need to change our code to use it. To quote Ronald Khoo: ================================================================ > Here is another place where SCO have made a serious mis-assumption. > They seem to have assumed that "tradition" is the only concern of Unix users. > It's not simply for a veneer of "traditional" behaviour that we want to > be able to do /bin/rm -f /tcb, remember that whole Unix way of > doing things is by tying programs together in an ENVRONMENT. > > If you break this environment, people who only use integrated applications > like MS-DOS users will be fine, but the rest of us will suffer (read: find > another vendor) because OUR SYSTEMS WON'T WORK ANYMORE. ================================================================ Clear now? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
ronald@robobar.co.uk (Ronald S H Khoo) (12/28/90)
chip@tct.uucp (Chip Salzenberg) writes: > So to port VMS to the 386, > you'd have to translate all the assembler code, the BLISS language > support and the FORTRAN language support to the 386. Umm... I'm sure that lots of VMS is heavily machine-dependent on the VAX architecture as well. It's easy to write unportable code in a portable language, as many of us have had the dubious pleasure of finding out. > 1. User info is spread out. Besides /etc/passwd, you must have a file > /tcb/files/auth/<first letter of user>/<user>. Some of the fields > in the auth file duplicate fields in /etc/passwd. So forget using > vi on /etc/passwd. Actually, I *do* vi /etc/passwd, then I run a hack script (appended). Warning: do not use this script, as it will void your SCO warranty. It probably also makes vast assumptions on the rest of the contents of my /etc/auth/** ... be warned -- FYI only :-) > To quote Ronald Khoo: Eee.. *I* get quoted in this context ? Does this mean I'm now on SCO's deathlist ? :-) Here's that hack. Give you some kind of idea what Chip was going on about, #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # /local/tcbgen # This archive created: Thu Dec 27 22:10:15 1990 export PATH; PATH=/bin:$PATH echo shar: extracting "'tcbgen'" '(877 characters)' if test -f 'tcbgen' then echo shar: will not over-write existing file "'tcbgen'" else sed 's/^X//' << \SHAR_EOF > 'tcbgen' XAUTH=/tcb/files/auth XPASSWD=/etc/passwd XDFLT=/etc/auth/subsystems/dflt_users XTTYS=/etc/auth/system/ttys Xexport AUTH PASSWD DFLT Xaprog='umask 007 ; awk -F: '"'"' X$2 != "*" { X letter = substr($1, 1, 1) X fnam = letter "/" $1 X print $1 ":u_name=" $1 ":u_id#" $3 ":u_pwd=" $2 ":u_lock@:chkent:">fnam X print $1 >> "'"$DFLT".n'" X}'"'"' $PASSWD' Xcp $DFLT $DFLT.n Xchmod 664 $DFLT.n Xchown auth $DFLT.n Xcd $AUTH Xsu auth -c 'mkdir a b c d e f g h i j k l m n o p q r s t u v w x y z ' \ X 1>/dev/null 2>&1 Xsu auth -c 'chmod 770 [a-z]' Xsu auth -c "$aprog" Xsu auth -c 'chmod 070 [a-z]' Xsort -u $DFLT.n > $DFLT.nn Xrm -f $DFLT.n Xfind /dev -name "tty?*" -a ! -name "ttya*p" -print | sed s,/dev/,, | X awk '{ print $1 ":t_devname=" $1 ":t_lock@:chkent:" }' > $TTYS.n Xchown auth $DFLT.nn $TTYS.n Xchgrp auth $DFLT.nn $TTYS.n Xchmod 664 $DFLT.nn $TTYS.n Xsync Xmv $DFLT.nn $DFLT Xmv $TTYS.n $TTYS Xsync SHAR_EOF if test 877 -ne "`wc -c < 'tcbgen'`" then echo shar: error transmitting "'tcbgen'" '(should have been 877 characters)' fi chmod +x 'tcbgen' fi # end of overwriting check # End of shell archive exit 0 -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
libove@libove.det.dec.com (Jay Vassos-Libove) (01/04/91)
In article <277916E3.2042@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: I speak only for myself, not for DEC. From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.unix.sysv386 Date: 26 Dec 90 21:32:19 GMT References: <2777E87B.6392@tct.uucp> <29027@usc> <29029@usc> >Moreover, in the process, DEC abandoned it's own ULTRIX >(DEC proprietary version of UNIX) in order to adopt SCO UNIX. SCO UNIX has ready support for *multiprocessing* (SCO MPX). ULTRIX doesn't. I'll bet that this consideration was probably the most important one. This advantage is utterly unrelated to any security issues. (Also, ULTRIX hasn't yet been ported to the 386; such a port would likewise be no small job, though infinitely easier than VMS.) Actually, Ultrix, as of version 4.0, does support multiprocessing. The DECSystem 5820, 5830, and 5840 are respectively 2, 3, and 4 processor models of an 18 MIPS RISC system, running Ultrix. -- Jay Vassos-Libove libove@libove.det.dec.com Digital Equipment Corporation decwrl!libove.det.dec.com!libove Detroit ACT/Ultrix Resource Center Opinions? They're mine, mine, all mine! Farmington Hills, Michigan and D.E.C. Can't have 'em!