Re: Connect internal

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3aab64c3$1_at_news.iprimus.com.au...
>
> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
> news:tamo7dmserf809_at_beta-news.demon.nl...
> >
> > "Van Messner" <vmessner_at_bestweb.net> wrote in message
> > news:5Azq6.1412$FQ3.131727_at_monger.newsread.com...
> > > connect sys as sysdba then change the sys password
> > >
> > >
> > > "fogun" <nospam_at_spam.net> wrote in message
> > > news:a_yq6.1167$T45.597968_at_news2.cableinet.net...
> > > > Hi all,
> > > >
> > > > Can anyone explain to me why I can issue an connect internal command
 at
> > > > SQL>? and it connects to the database without using a password. If I
 issue
> > > > the same command connect internal/password, gives the same result.
> > > >
> > > > How can I protect connect internal.
> > > >
> > > > F
> > > >
> > > >
> > >
> > >
> > Sorry to say so, but this answer is incorrect.
> > As he is capable of using connect internal without password he uses OS
> > authentication. So changing the password wouldn't make any difference.
> > Of course this works on the server only.
> > On NT you could try to remove the ORA_DBA local group.
> > On Unix implementations of Oracle you can't disable this at all, and why
> > should you, as you are already connected to the server as a privileged
> user.
>
>
> I may be wrong, but I thought on Unix that it was membership of the 'dba'
> group that gained you O/S authentication rights. Hence, removal of that
> group, or all entries within it, would effectively 'switch off' O/S
> authentication on Unix, and force the use of Password File authentication.
>
> I can't see why Unix should be different in this regard as compared with
 NT
> (but I'm willing to learn!)
>
> Regards
> HJR
>
>
>
>
>
>
>
> >
> > Regards,
> >
> > Sybrand Bakker, Oracle DBA
> >
> >
> >
> >
>
>
Well one thing is for sure: the dba group used on install is linked into the code. So I would expect strange errors once you remove this groups. I did see errors (mainly ORA-1034) when the uid and the gid of the Oracle owner didn't comply with the uid and the gid used at install. (This was in a system running NIS, where the NIS database showed different uids and gids from the local /etc/passwd and /etc/group)

Regards,

Sybrand Bakker, Oracle DBA Received on Sun Mar 11 2001 - 14:13:59 CET