Re: sysdba privileges and shutdown

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Sat, 08 Mar 2003 09:03:08 +1100
Message-ID: <pan.2003.03.07.22.03.07.609752@yahoo.com.au>

On Fri, 07 Mar 2003 22:44:10 +0100, Sybrand Bakker wrote:

> On Sat, 08 Mar 2003 06:27:27 +1100, "Howard J. Rogers"
> <howardjr2000_at_yahoo.com.au> wrote:
> 

>>
>>> 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.

> NOT true. You still can have a password file. Whether it is used or
> not is a different matter. If you want to nit-pick then you'd better
> prepeare yourself.

Nitpick away. If it is set to NONE then of course you can have a password file in existence, just as you can have pretty much any file you like sitting on a hard disk doing sod-all. But it isn't used, and as far as Oracle is concerned, doesn't exist.

> 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.
> Did I say something else. Geeeeeeeeezzzzzzz

Yes. You said that "only internal has sysdba privilege". ANYONE who is in the dba group has sysdba privilege when r_l_p is set to none. You also stated that "SYS doesn't have sysdba privilege" under such conditions. Which is also not true, since anyone in the dba group who connects will actually be logged on as SYS.

> 

>>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.

> 
> R_P_L=shared will allow you to connect sys as SYSDBA from ANYWHERE IN
> A NETWORK. R_P_L is none will allow SYSDBA on the server only.
> Please try to read before having me look like silly

Actually, the parameter concerned is R_L_P, not R_P_L. ;-)

As for the substantive point in hand, if you think what O/S authentication means, then it is blindingly obvious that you cannot connect as sysdba from a remote machine unless you have a password file, since you aren't using the O/S that's been set up with a dba group, but the O/S on your PC. (We'll draw a veil over Windows for now).

No-one's trying to make you look silly, Sybrand. Only you can do that.

HJR Received on Fri Mar 07 2003 - 16:03:08 CST