Re: Who's internal ?

Comments embedded.

Also I recommend you to check the documentation on the various values of remote_login_password_file.

Basically connect internal *with* a password is being used when you are not on the database server.
Start a session on the server
use
set instance <servic_name>
now issue
connect internal
and you will be asked for a password.

In a proper install, you can use connect / as sysdba on the server *always*, and this applies to 7.3, 8.0 and 8i.

I would strongly recommend you to reread the documentation. Your understanding of SYSDBA/SYSOPER is incomplete, and it is dangerous you post it in this fashion

Regards,

Sybrand Bakker, Senior Oracle DBA

"Randy Harris" <harrisrATbignet.net> wrote in message news:tp13adna5m1s29_at_corp.supernews.com...
> Well... This actually has changed quite a lot over the last few releases
of
> Oracle. With Oracle 7, the only method was connect internal, then supply
> the internal password. Anyone that had the password and access to the
> system could connect internal.

On both Unix and NT this statement with respect to Oracle 7 is *false*
>
> Starting with Oracle 8, several new options were included, which, while
> adding a bit of setup complexity, offered a great deal more flexibility.
> The connect internal is still supported for backward compatibility, but
> Oracle can be configured to use OS authentication instead. Once
configured,
> simply granting a user the OSOPER privilege, in the OS, permits the user
to
> connect internal and startup and shutdown the db.
>

This was already possible in Oracle 7.
> A completely different method is also available, using the ORAPWD utility.
> This utility creates and maintains a separate password file for Oracle's
> use. SYSOPER and SYSDBA privs can then be granted using ORAPWD. This
> method, though a bit tougher to set up, is considered the more secure.

This was also already available in Oracle 7.

The use of the passwordfile is dependent on the value of the parameter remote_login_passworfile

parameter               internal            sys             other users
none      1)              sysdba            no sysdba    no sysdba
                              sysoper           no sysoper  no sysoper
shared    2)             sysdba            sysdba         no sysdba
                              sysoper           sysoper        no sysoper
exclusive                 sysdba            sysdba         grantable
                              sysoper           sysoper        grantable

1. this means anyone knowing the internal password can connect with SYSDBA priviliges from any system
2. this means any user knowing the SYS password can connect sys/<password> as sysdba

ternal.
> >
> > Randy, I was always a bit puzzled by this. How does one give
> > only have a certain set of network users rights to connect as
> > internal?
> >
> > --
> > Galen Boyer
> > It seems to me, I remember every single thing I know.
>
>
Received on Sat Sep 01 2001 - 13:38:09 CDT