Re: Forced to use OPS$ in 7.0.16 - Yuck!
Date: Wed, 25 May 1994 14:27:41
Message-ID: <cj10.13.000E768C_at_ucs.cam.ac.uk>
In article <l.carl.pedersen-240594143329_at_kip-sn-71.dartmouth.edu> l.carl.pedersen_at_dartmouth.edu (L. Carl Pedersen) writes:
>in 7.0.15 and earlier, they did this differently, so we could have
>passwords on accounts *and* let VMS users into accounts with matching names
>- without using OPS$.
>the way it works now is almost more obnoxious than it was in ORACLE 6. i
>would not be so annoyed if they hadn't led us to believe OPS$ was going
>away, but they seem quite adamant that it will continue to work the way it
>is now.
>i assume it works the same way on other operating systems as it does on
>VMS. true?
I was furious when I read about this.
I have a Unix server and several PC clone client machines. I have set the OS_AUTHENT_PREFIX to null, and start SQLNET (V1) with OPSOFF. Many of my oracle users have Unix accounts on the server with usernames the same as their oracle usernames. They also have real Oracle passwords.
If already authenticated to the Unix on the server, these users can connect to Oracle without quoting a further password. However, from the client PCs they must quote their Oracle passwords. This situation is eminently satisfactory.
It is most important from the point of view of security that cron jobs running on the server can connect without quoting a password, as it avoids the necessity to store a password in clear. It is also important that (by using the .rhosts mechanism), users authenticated on other trusted machines can start processes on the server which connect to Oracle without quoting either a Unix password or an Oracle password.
If 7.0.16 is really as reported, I don't know what I shall do. I will need the compatibility bridge, but since I have already got rid of the OPS$ prefix, it won't be available to me.
What I need is an init.ora parameter to restore the 7.0.15 behaviour, and a promise that the old behaviour will remain for the foreseeable future.
Would anyone from Oracle inc be prepared to comment on this. Received on Wed May 25 1994 - 14:27:41 CEST