Re: ? Passing userid/password

In article <C9GAxr.A29_at_odin.corp.sgi.com>, guest_at_sgi.com (Guest Account) writes:
|> In article <1993Jun30.143130.19167_at_newsgate.sps.mot.com> ttg242_at_newton.sps.mot.com writes:
|> >In article 68s_at_uk.ac.brookes, p0070621_at_oxford-brookes.ac.uk (Tommy Wareing) writes:
|> >Stuff deleted ...
|> >>
|> >>***HAVING THE PASSWORD AS AN ENVIRONMENT VARIABLE IS NOT SAFE***
|> >>
|> >>This may not be the case under other OS's, but do you really want to
|> >>risk this?
|> >>
|> >>Either use an OPS$ username, or make it a user exit (which will give
|> >>you the most flexability anyway).
|> >>
|> >Also not secure in a SQL*Net environment. I can create a user on my
|> >machine with your userid and use that to log into your OPS$ account
|> >on your machine (or any other come to that).
|> >
|> >---
|> >Regards,
|> >David TvE
|> >
|> >
|> >
|>
|> I'm quite sure David is wrong (Sorry !). For what he says to happen, the remote
|> process on "your" (see above) machine should be created under the same usercode,
|> which could be controlled. I've worked in a system where OPS$ usercodes worked very
|> successfully (in a SQL*NET env).
|>
|> Could someone clarify ????
|>
|> ram

David, is correct for UNIX. VMS allows you to setup a list of trusted nodes. Only nodes on the list can talk to the Oracle server, no matter if they are ops$ accounts or not. VM doesn't allow ops$ connections across the net at all. You can disallow ops$ connections across the network when you startup the sql*net daemon on the server.

                                  Ian MacGregor
                                  Stanford Linear Accelerator Center
                                  (415) 926-3528