home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / oracle / 2148 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!cunews!revcan!micor!vicuna!frampton
  2. From: Steve Frampton <frampton@vicuna.ocunix.on.ca>
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: How to disable '$' DCL shell?
  5. Keywords: vax vms oracle sqlplus
  6. Message-ID: <B7DwTB3w165w@vicuna.ocunix.on.ca>
  7. Date: Sat, 07 Nov 92 21:02:10 EST
  8. References: <HVXRTB1w165w@vicuna.ocunix.on.ca>
  9. Reply-To: frampton@vicuna.ocunix.on.ca
  10. Followup-To: comp.databases.oracle
  11. Distribution: world
  12. Organization: Vicuna Systems, Kingston, ON (613) 547-5066
  13. Lines: 50
  14. Content-Type: text/plain; charset=us-ascii
  15.  
  16. Steve Frampton <frampton@vicuna.ocunix.on.ca> wrote:
  17.  
  18. > Hi everyone:
  19. > 
  20. > I would like to find out how to disable the '$' shell to DCL from SQLPLUS
  21. > for the comp. services dept. @ my place of employment.  This seems to be
  22. > somewhat of a security hole and if there is a simple way to disable users
  23. > from accessing it how is it done?
  24.  
  25. As promised, I am following up here with a summary.  Special thanks to
  26. all who responded:
  27.  
  28.     sinha@bms.com, rsingi@penuts.enet.dec.com, rwk@netcom.com,
  29.     hatzinger_m@bmwf1f.bmwf.gv.at, jbennett@netcom.com,
  30.     andy@homebase.vistachrome.com
  31.  
  32.     ...and anyone else who happened to respond just during or after
  33. I put together this followup.
  34.  
  35. Although the above people could have told me to RTFM (someone told me
  36. that the information was in Appendix E of the SQL*Plus manual -- but
  37. gave me the pertinent information anyways), they were all very helpful,
  38. telling me basically to add an entry to the 'PRODUCT_USER_PROFILE'
  39. table to disable any required commands for unauthorized users.
  40.  
  41. The trick is to log into ORACLE as system and insert the required info
  42. into the table similar to:
  43.  
  44. insert into PRODUCT_USER_PROFILE 
  45.         (PRODUCT,USERID,ATTRIBUTE,CHAR_VALUE)
  46. values      ('SQL*Plus','OPS%','HOST','DISABLED');
  47.  
  48. 'SQL*Plus' must be entered in exactly as shown, and the userid as well as
  49. the attribute (command) must be entered in uppercase.  The userid may be a
  50. specific userid, or wildcards can be used as well.
  51.  
  52. To re-enable a command simply delete the row from the database.
  53.  
  54. It was also suggested that I should make sure other users do not have 
  55. access to the PRODUCT_USER_PROFILE table or they would be able to simply
  56. circumvent any changes made!
  57.  
  58. Thanks again for all the timely and helpful responses!
  59.  
  60. +-----------------------------------------------+--------------------+
  61. | Steve Frampton - frampton@vicuna.ocunix.on.ca | Steve Frampton     |
  62. | I collect postcards!  If you send me one from | 501-A Princess St. |
  63. | your area, I'll send one in return.  Send to >| Kingston, Ontario  |
  64. | (Don't forget both email and mailing address) | CANADA   K7L 1C3   |
  65. +-----------------------------------------------+--------------------+
  66.