Re: create account with id & password same

In article <345k6v$d02_at_news.nynexst.com>, farber_at_nynexst.com (Martin Farber) writes: [...]
|> >Shouldn't that be:
|> >
|> >create user ops$doofus identified externally;
|> >grant connect, resource to ops$doofus;
|> <<< STUFF DELETED >>>>
|>
|> Actually, you're both right - on version 7.x anyway. The advantage of the first
|> over the second is that it allows login by another OS user that knows the Oracle
|> password - without logging, or su'ing , in as doofus. Version 7.x also allows you
|> to change the silly OPS$ prefix in an ora parameter. This might help UNIX folk
|> that want to log in as doofus and not have to quote the $:
|>
|> sqlplus ops\$doofus/blahblahblah

Yes, it would be really useful to have oracle userids that can get automatic authentication via the host Unix system, *and* can be accessed by knowing the oracle password. In versions of Oracle 7 prior to 7.0.16 you could do this as outlined above.

Unfortunately, in 7.0.16, the rules have been changed. Authentication by conversion of host userid to oracle userid is only allowed if

  either, the oracle userid is "identified externally"   or, the prefix string has not been altered from the default of OPS$

Moreover, the way Oracle explain (or fail to explain) this change suggests that the second option is there only for backwards compatibility with Oracle 6, and may disappear in some subsequent release.

We got bitten by this. We have applications where user registration changes relevant to various client systems are collected by those systems rsh'ing to the server as a Unix userid specific to that client system, which has a "login shell" that does an oracle login automatically. This is so that we can use the .rhosts authorisation mechanism (to trust "root" and administrators on the client) rather than passing passwords around. However, there are tables and other apparatus owned by the oracle userid, and it was convenient to be able to maintain them by doing an oracle login as that user, quoting its password. Now that such users have to be "identified externally", we can't do this any longer, and have to overuse other oracle privileges to do the maintenance activities.

Disclaimer: I am an observer (an administrator of one of the client systems in fact) rather than the implementor [Charles Jardine] of the apparatus described in the last paragraph. I hope I have most of the details right, though.

Chris Thompson
Cambridge University Computing Service
Internet: cet1_at_ucs.cam.ac.uk
JANET: cet1_at_uk.ac.cam.ucs Received on Sat Sep 03 1994 - 18:25:42 CEST