This is quite confusing, and hence I thought to better disclose it here. Actually I am current in an experimental setup of Business Objects, which finally led me to land up in the question “’oinstall’ or ‘dba’?” — that is years old and I don’t think this is yet answered properly or I understood it properly.
Oh..I forgot to mention that I am installing Business Objects with Oracle Database on a Linux (SuSE Linux Enterprise Server 10 SP2). Before installation I have created both the group ‘oinstall’ and ‘dba’ as it says in the installation manual. I had basically three things in mind.
- I should have an oracle directory/inventory owner / manager….He/she should not be able to database administration.
- I should have a database administrator who should have the full access to database admin but must not be able to do or change the directories/binaries.
- I should have a database user, who should not be able to database admin but will be able to do login into one particular schema he is assigned to. Let say it is ‘scott’.
Earlier I never used to give it (the Question — “’oinstall’ or ‘dba’?”) much of an importance, but this is now required and last three days I am searching internet for a very concise answer, on the possibility of meeting the 3 above conditions.
So what I did? I have installed Oracle – mentioning ‘dba’ as Unix DBA group and inventory and ‘oinstall’ as the operating system group who has the write permission to oracle inventory directory. I did the installation from a user ‘oratst’ whose primary group is ‘oinstall’ and other groups are ‘dba’ and ‘oper’. Hence ‘oratst’ is the inventory owner.
What I observed is a user who is not a member of ‘oinstall’ group (at least one of the secondary group of the user is not ‘oinstall’ can not traverse to ‘ORACLE_HOME’, ‘ORACLE_HOME/bin’, ORACLE_HOME/lib etc and hence will not be able to execute ‘sqlplus’ or any other binary.
If I create one user whose primary group is DBA and secondary is ‘oinstall’ , this user can do ‘sqlplus / as sydba’ i.e. do not need a password to be supplied to login as ‘SYSDBA’.
Similarly if I create a user whose primary group is ‘oper’ and secondary group is ‘oinstall’ and this is user is not a member of group ‘dba’, then this user will not be able to login as ‘sqlplus / as sydba’. But it will be able to do login in any of the user using database user name and password.
Apparently the above 3 goal is achieved…No not, it is achieved partially. I have checked if I remove the secondary group’ dba’ from user apparently it is a no harm, in fact I have removed the group membership of ‘oper’ too. Although I didn’t checked yet whether it is going to create a problem for me when I am applying patch. Till this time I have not yet started to apply the patch.
Secondly, any user who is able to connect database supplying a username and password, will be able to login as ‘sysdba’ provided he/she crack/steal the password of database user ‘sys’. At a first step I did created a long and strong password, but it would have been if I could have restricted him from the operating system two. i.e. except the ‘dba’ group member nobody should be able to login as ‘sysdba’ even if he/she guess the password. But complete security will come into picture, if and only if we also check and devise a method by which a user can be restricted to modify his group membership. Only then the above three goal can be achieved properly……….