home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / sysv386 / 13326 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.7 KB  |  78 lines

  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!wupost!gumby!destroyer!mudos!mju
  3. From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
  4. Subject: Questions about MAS90 from SOA
  5. Message-ID: <Bt7stA.1o3@mudos.ann-arbor.mi.us>
  6. Date: Wed, 19 Aug 1992 05:05:25 GMT
  7. Organization: The Programmer's Pit Stop, Ann Arbor MI
  8. Lines: 68
  9.  
  10. The company I work for (who shall go unnamed) is very seriously
  11. considering switching over to the MAS90 accounting system from State
  12. of the Art Software running under SCO Unix 3.2v4.0.  Currently we are
  13. using a system written in FoxBase under DOS by an in-house programmer;
  14. however, that system is buggy, and the person who wrote it no longer
  15. has time to support it.
  16.  
  17. I've gotten an evaluation copy of MAS90 from SOA, and have installed
  18. it on our system.  Having done so, however, I've started to have MAJOR
  19. qualms about both MAS90 and about SOA in general.  Why?  Well...
  20.  
  21. 1. All of the MAS90 files and directories are installed with 777
  22. permissions.
  23.  
  24. 2. The BBx interpreter, which is used to run MAS90, is installed owned
  25. by root and with the SUID bit set.
  26.  
  27. 3. MAS90, as installed, allows the user to run /bin/sh through an
  28. undocumented shell command.  Because of point (2) above, this means
  29. that any MAS90 user can get a root shell.
  30.  
  31. 4. MAS90 has a somewhat alarming tendency to drop the user to the
  32. BBx BASIC prompt if it encounters a specific error condition (mostly
  33. with a printer that is not hooked up).
  34.  
  35. 5. MAS90 is written with the assumption that a user will always be
  36. logging in from the same port.  This assumption does not hold if you
  37. are running it in an environment like ours, with users accessing the
  38. Unix system over a TCP/IP network with telnet.
  39.  
  40. 6. MAS90 pretends to use the standard Unix termcap format, but has
  41. made several proprietary and incompatible extensions to it that force
  42. you to use a separate termcap file.  (For example, it uses MA and MB
  43. to turn on and off high-intensity mode.  What was wrong with so and
  44. se?)
  45.  
  46. 7. MAS90 is run by logging in as "mas90", and then giving MAS90 your
  47. MAS90 usercode and password.  This is very inconvenient, since all of
  48. our other applications are run by logging in as a normal user.  In
  49. addition, all of our users have their own login-id; if they are all
  50. logged in as MAS90, it becomes impossible to find out who's logged in.
  51.  
  52. Although it is possible to fix most of these problems (I haven't yet
  53. found a fix for (4) above, but have gotten the rest of them mostly
  54. solved), I'm still left with a very bad feeling about MAS90.  It
  55. honestly looks like the BBx and SOA folks just took their DOS product
  56. and recompiled it under Unix, without any thoughts to the differences
  57. in paradigm between DOS and Unix.
  58.  
  59. Unfortunately, I'm having some trouble convincing the powers-that-be
  60. that MAS90 is a bad idea.  So, I'm turning to the net: Does anyone
  61. have experiences, either positive or negative, with MAS90 in an SCO
  62. Unix environment?  Does anybody have any tips or tricks that could
  63. make working with MAS90 more enjoyable/bearable?  Basically, I'm
  64. looking for convincing arguments on why we shouldn't go with
  65. MAS90, as well as ways of making MAS90 more Unix-like if we end up
  66. going with it anyway.  And while we're at it, are there any other
  67. programs for Unix with similar functionality but more orthodox design?
  68. (By similar functionality, I mean software that handles a client
  69. database, inventory management, purchase orders, invoices, and so
  70. forth.  Your basic core-business type stuff.  We are a computer
  71. reseller, so if there's anything geared to the needs of that sort of
  72. company, that would be best.)
  73.  
  74. -- 
  75. Marc Unangst                | Real men don't make backups.  Real men never
  76. mju@mudos.ann-arbor.mi.us   | accidentally delete files that they're going
  77.                             | to need later.
  78.