[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:	DEC Rdb against the World

Moderator:	HERON::GODFRIND

Created:	Fri Jun 12 1987
Last Modified:	Thu Feb 23 1995
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1348
Total number of notes:	5438

139.0. "Security in Oracle (and Others)" by TRCT01::ROUS (Colin Rous @TRC DTN 637-3187) Fri May 20 1988 02:10

   I am a consultant in Canada providing Sales Support specifically in
   computer security.  One of the selling points for Rdb is the tight
   integration of its access control capabilities into those of VMS (ACLs
   on views and tables).  I am starting to get frequent questions from
   customers and prospects on how Rdb's security features compare to those
   of other relational databases, most usually Oracle.  Unfortunately, I
   know next to nothing about the security features of *any* other VMS
   based relational databases. 
   
   Security consists of three factors:  availability, integrity, and
   confidentiality.  The first includes things like failover, journalling,
   cluster support, etc.  The second includes those and also adds the usual
   integrity capabilities like two phase commit.  The third, of course,
   concerns file protection, access to views and tables, ACLs, etc.  I
   would very much appreciate information, or pointers to information,
   comparing the security features of Rdb to that of Oracle.  (I have seen
   some notes and articles on availability or integrity, but none on
   confidentiality and none which treat the subject as a whole.)  Actually,
   if any of you have the time, patience, and knowledge, I am interested in
   the same information for *all* our major database competitors. 
   
   I know this is not a trivial request, but the way things are shaping up,
   in our country, anyway, in at least some situations security features
   will make the difference between winning and losing the sale.  I have
   had users of other products tell me that if they had known of Rdb's
   access control capabilities *before* they bought, they would have
   considered it more carefully. ('Course they apparently didn't care
   enough before they bought to even ask the question. :-( ) 

   My thanks in advance for any contributions.  (A similar note has been
   posted in HUMAN::SECURITY_INFORMATION.)

T.R	Title	User	Personal Name	Date	Lines
139.1	Security	KOKO::DAVIS	Outer Joins are Un-Natural	`Tue May 24 1988 18:36`	19
	Concerning Availability: See notes regarding ORACLE in clusters, ORACLE in general and AI journaling. My own experiences with ORACLE (not on a VAX) were of a very fragile system which failed frequently. Concerning Security: Oracle supports security only to the extent that SQL does. This provides Table, column and row (the latter 2 via Views) levels of security. ACL's are not supported since the kernel opens all files on behalf of all users and then controls access thru its own mechanisms. Stringent security it not one of ORACLE's strong suits. I am willing to discuss this in more detail over DTN or thru VAXmail (DTN 277-7083, VAXmail= KOKO::DAVIS) Sandy
139.2	Lookup Redundant: Says See Redundant	VAOU02::NJOHNSON	Westcoast Wiz	`Thu May 26 1988 10:28`	7
	The only thing I can contribute to this is that Oracle seems to need to keep it's own profiles of users. That means that you must have a VMS SYSUAF entry as well as one in the Oracle Profile before you can access an application. There is no integrated security strategy with Oracle, and because of their 'multi-vendor' approach, they cannot take advantage of any one O/S's security features.
139.3	Remote db usage	HSK01::MANNISTO	Olli Mannisto, SWAS/SW Technology, Digital Finland	`Fri May 27 1988 14:05`	12
	You may use Orcale db as a remote db thru SQL*NET. To have the VMS username based security features available you must have the same user accounts on the db (server) side as on the side where the program runs. RDB seems to check db related ACLs on the node where the users are. So you need just one account for the db server process (processes). -- Olli
139.4		CGOS01::MHAMMEL	Downpayment Blues	`Fri May 27 1988 22:37`	14
	Please note that this was based on a version of Oracle I saw approximately one year ago, so things might have changed. Anyway, this version of Oracle (on VAX/VMS) did security by assigning a 'username' and 'password' to each database. The thing I really found laughable about the whole thing was that the file which contained these names and passwords was an ASCII file, with no attempt at encryripting the passwords. So, if that thing wasn't protected properly, just TYPE it to see all the passwords to all the Oracle databases on the system. Maury...
139.5	yes - username & password still needed	SNOC01::PARKER	Jeff Parker	`Sat May 28 1988 08:08`	2
	I went to an Oracle demo just the other week; and yes, you still have to provide usernames & passwords for access to databases.
139.6	passwords now encrypted	TPUNIV::ROARK	Tim Roark @DYO SWS CSOA1::,DYO780:: or TPUNIV::ROARK	`Sat Jun 04 1988 23:00`	3
	re .4 not encrypted in V4.x, encrypted in 5.x tim
139.7	OPS$login skips username password	USHS08::SPARKS		`Mon Jul 11 1988 20:41`	27
	Oracle allows VMS users to choose between using the secondary security or not. If the DBA setting up the user accounts precedes the username by OPS$ then oracle looks at the name and if it matches the VMS username access is allowed without a secondary username and password. This allows VMS users to login to oracle without re-entering and maintaining a 2nd password. The DBA or Manager who set up the account can log into that persons oracle system by entering OPS$username/password. This allows the manager to access oracle systems other than his own. Oracle scheme on data security has 4 basic levels and 1 special level. The 4 basic levels are self explaining they are INSERT, UPDATE, DELETE, and SELECT. The special level is ALL where the person granted access can drop the table or create indexes on it. The access is granted with or without grant option meaning the person given access can give it on down. This is popular with shops that develop a system and give the manager of the department privelage and let them control security rather than DP controlling it. By direct and indirect (using views) methods the access of each of these 4 levels can be controlled down to the individual field level. Also security can be controlled with results, a view can be set up so a manager can only see the budget of the managers below him, not above, and the controller can see all is an example I have seen. Hope this helps, sorry it's not more timely, haven't checked in lately.