home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!ucbvax!NSCVAX.PRINCETON.EDU!dragon
- From: dragon@NSCVAX.PRINCETON.EDU (Mighty Firebreather)
- Newsgroups: comp.os.vms
- Subject: RE: operator accounts
- Message-ID: <00966EFB.9C07C540.2017@nscvax.princeton.edu>
- Date: 21 Jan 93 15:02:23 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Distribution: world
- Organization: The Internet
- Lines: 35
-
-
- (No name given) <CXNHJP@manadon-engineering-college.ac.uk> writes:
- >
- >Could anybody out there please tell me what the best way to set operator
- >accounts up is, ie. should the different operators go though their own accounts,
- >or should there be a common account with full privs. Is it possible to give
- >privs only on request using com, exe programs without having to give the
- >setprv priv initially .... ???
- >
- >Any thoughts on this subject would be greatly appreciated.
- >
-
- Operators should have their own accounts for accountability.
- Operators should *NOT*, in general, have full privileges. They should have
- *only* the privileges necessary to do their jobs. I'd start by giving them
- OPER, and WORLD.
-
- Operations requiring other privileges should probably be done from
- captive accounts. BACKUP is a good example; it requires READALL privilege
- or BYPASS; privileges which, in principle, give the holder total control of
- the system and allow, in practice, complete freedom to do anything at all
- to any file on the system.
-
- Another advantage of doing BACKUP from a captive account is that
- you can be reasonably sure that BACKUP is being done the way you want it
- done.
-
- *************************************************************************
- * *
- * Here, there be dragons! *
- * dragon@nscvax.princeton.edu *
- * *
- * Richard B. Gilbert *
- *************************************************************************
-
-