Oracle数据库非Dba角色用户使用as sysdba仍然可以连接相关问题

1. Oracle 默认的三个重要角色

CONNECT                         创建session角色
RESOURCE                        创建资源角色,Create table 等等
DBA                                 数据库管理员角色
   

参考网址:http://www.blogjava.net/caihaibo2008/archive/2008/12/11/245723.html

2. Oracle有两个具有dba角色的用户,分别是sys与system,他们都可以以sysdba身份登录数据库。既然system具有dba角色,为什么还分配他sysoper身份?

   【sys】所有oracle的数据字典的基表和视图都存放在sys用户中,这些基表和视图对于oracle的运行是至关重要的,由数据库自己维护,任何用户都不能手动更改。sys用户拥有dba,sysdba,sysoper等角色或权限,是oracle权限最高的用户。
   【system】用户用于存放次一级的内部数据,如oracle的一些特性或工具的管理信息。system用户拥有普通dba角色权限。

其次的区别,权限的不同。
   【system】用户只能用normal身份登陆em,除非你对它授予了sysdba的系统权限或者syspoer系统权限。
   【sys】用户具有“SYSDBA”或者“SYSOPER”系统权限,登陆em也只能用这两个身份,不能用normal。

3. 在今天的数据库实验课上遇到了如下所示的问题:

    如上图所示,SYS用户可以正常登录数据库,但是其他用户、甚至随便乱写,以as sysdba的方式也可以成功连接数据库,并且show user显示的仍然是SYS,这是什么原因呢???


Oracle登录的时候有三种登录验证机制

   1. 操作系统验证

   2. 密码文件验证

   3. 数据库验证

     一般权限用户的登录验证都是第三种方式,即数据库验证,因为用户名和密码都是存储在数据库当中的。然而,SYS用户(具有SYSDBA和SYSOPER权限的用户)却不是数据库验证。在oracle数据没有启动的时候,SYS用户就可以连接到数据库,并对其进行启动等操作,所以不可能是数据库验证。SYS用户采用的是第一种和第二种验证方式。

     Linux下Oracle的启动过程

     lsnrctl start 启动监听(接收用户请求)。此时数据库没启动,所以不能验证普通权限用户

     sqlplus /nolog 启动sqlplus

     conn sys/oracle as sysdba,监听看到是sysdba用户,就进行操作系统验证或者文件验证,如果正确

     startup 启动数据库实例。

     当此时再以普通权限用户连接时,就直接将请求发送给数据库进行数据库验证。

     

     Windows下Oracle的启动过程

     lsnrctl start 启动监听

     oradim -startup -sid orcl  将复杂的过程封装了

     

     conn /  as sysdba;  这样写居然可以连接!或者随便写个名字都可以连接,只要/保留就可以。如下图:


     因为,默认采用的验证方式是操作系统验证!如下图所示,在计算机管理里面的ORA_DBA组有当前计算机操作系统用户uestcong



     当我把uestcong这个用户删除之后,再重新使用conn a/b as sysdba登录,就出现如下所示的情况了:


     显示权限不足,没有验证通过。

     以uestcong登录操作系统时,默认就是DBA管理员,在监听看到as sysdba时,就首先进行操作系统验证,操作系统的用户uestcong当然就能通过验证。当我把uestcong删除之后,就会用密码文件的方式验证,此时把sys和正确的密码重新连接时,就可以直接连接了。


     所以在使用oracle进行开发时,应该把操作系统验证取消,使用密码文件验证的方式。如果密码忘记,可以把密码文件删除,用新的密码文件代替就可以。

     密码文件的路径:D:\oraclexe\app\oracle\product\10.2.0\server\database\PWDXE.ora(PWDXE.ora我使用的是XE版本),当把密码文件删除时,再用正确的用户名密码连接,就无法进行连接了。


     感谢传智博客王治国的精彩讲解!

参考网址:http://topic.csdn.net/u/20110823/18/e9846996-22f4-4429-a7f5-47877a729ef0.html

展开阅读全文

没有更多推荐了,返回首页