home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21669 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: RE: operator accounts
  5. Message-ID: <9301210244.AA05110@uu3.psi.com>
  6. Date: 21 Jan 93 01:41:50 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 58
  11.  
  12.  
  13.     Could anybody out there please tell me what the best way to set
  14.     operator accounts up is, ie. should the different operators go though
  15.     their own accounts, or should there be a common account with full
  16.     privs. Is it possible to give privs only on request using com, exe
  17.     programs without having to give the setprv priv initially .... ???
  18.  
  19.     Any thoughts on this subject would be greatly appreciated.
  20.  
  21. There is no one best answer.  It depends on what you use your system for,
  22. what you expect your operators to do, how much training you expect them to
  23. have, and many other things.
  24.  
  25. There are some general rules:
  26.  
  27.     1.  Maintain accountability.  If someone does something on the system,
  28.         make sure you can track it back to them.  This is partly a
  29.         matter of security, on the "bull in the china shop" theory
  30.         (you can always buy new china, but the bull is dead meat),
  31.         but also just good management practice:  When something goes
  32.         wrong, it helps to find the person who changed things in
  33.         order to understand what he did and why and possibly change
  34.         it back.
  35.  
  36.         A single shared account instantly loses accountability.  It
  37.         also implies a shared password - usually a bad idea.  A
  38.         secret that's known by one person will stay secret; a secret
  39.         that's known by two may soon spread; one known by four or
  40.         five will quickly be known by yet more.
  41.  
  42.         Some sites use a single privileged account with an additional
  43.         "sign in" in a forced login file.  (Individual operators on
  44.         such a system usually get individual non-privileged accounts
  45.         as well.)  The theory is to provide a central log of operator
  46.         logins.  Often, the "sign in" asks for a one-line comment
  47.         about what the person intends to do.  This can be useful IF
  48.         you can convince everyone to give useful answers!  In most
  49.         cases, it quickly gets seen as just another pain in the neck
  50.         and the logs fill with "reasons" like "Fix system".
  51.  
  52.     2.  Give the minimum privilege required to get the job done.  An
  53.         operator who will only be doing backups needs READALL, but
  54.         really not much else.
  55.  
  56.     3.  Especially when dealing with untrained staff, it may be worth your
  57.         while to create captive scripts to let them do their jobs,
  58.         but nothing else.  For example, many sites have a "backup"
  59.         account which is runs a captive script.  All it can do is
  60.         backups.
  61.  
  62. In answer to your general questions:  Privileges can be associated with an
  63. executable image (using INSTALL), and you can restrict access to that image
  64. using either the SOGW (system/owner/group/world) protection mask or ACL's,
  65. which can give you very fine-grained control.  Privileges CANNOT be directly
  66. associated with a command file (though for cases like the backup script, you
  67. can get a similar effect).
  68.                             -- Jerry
  69.  
  70.