Re: sysdba privileges and shutdown

> Just to set things straight, adding to the answer of Tanel
>
> remote_login_passwordfile = none (the default) only internal (/ as
> sysdba) has sysdba privilege, SYS doesn't have sysdba privilege (this
> has changed in 9i)

Beg to differ. If remote_login_passwordfile is none, then you do not have a password file. Therefore, you must be doing privileged user authentication using OS techniques. Therefore, anyone who is included in the dba group (or its Windows equivalent) can log on as a privileged user. And a show user when having done so will report you to be SYS. And that was true in 8.0, 8i and remains true in 9i.

The only thing that has changed in 9i is that SYS can no longer log in as an *ordinary* user, but *only* as SYSDBA. And even that is not a permanent thing, but merely a consequence of o7_dictionary_accessibility defaulting now to FALSE. Set it back to TRUE, and even SYS can simply do a 'connect sys/password'.

> remote_login_passwordfile = shared: internal and SYS have sysdba
> privilege. This means *remote* connections on a client system could get
> privilege when connecting as SYS as sysdba

Not quite. R_L_P=shared means you are using password file authentication, but no real, human, users can be given the SYSDBA privilege and added into the password file. A 'grant sysdba to fred' will fail. But a 'connect sys/password as sysdba' will work. A connect / as sysdba might also work, since the mere existence of a password file does not suddenly switch off O/S authentication checks.

> remote_login_passwordfile=exclusive:
> ANY user, provided explicitly granted, can have SYSDBA privilege
>

Regards
HJR Received on Fri Mar 07 2003 - 13:27:27 CST