Re: Oracle & UNIX password

Kirill Richine wrote:
>
> Robert W. Swisshelm (swisshelm_at_lilly.com) wrote:
> : with a / from the server, and specify the username/password from the
> : client.
 

> : create user ops$fred identified by wilma .... ;
>
> I am not sure what you associate with "eating the cake" but for me the
> best cake is not to have to mess with users' passwords. In UNIX, when
> you set a new ID, you can leave it blank and make the account invalid,
> then when the user is ready to log on, he phones you, you validate the
> login, he rlogins and sets his own password, which he can change later
> on. While this is happening, you watch the who, making sure that there
> are no impostors, and also ask him whether he made it successfully.
>
> Now, the question is, is something like this possible in
> client-server? From your example above, I see that you have to type
> this "wilma" thing -- this is what I am trying to avoid. If I had to
> do it, then what's the point of having ops$ logins -- all users will
> be connecting via sqlnet anyway, so what's the point?
>
> Thank you.
> k&

If all your users are connecting in through clients, then they don't need a unix account, so there is no point in having an ops$ oracle account. The background processes created for the sqlnet connections are owned by oracle, not by the user. So, their oracle account does not need to have the OPS$ prefix. You now have only 1 account to maintain, the oracle account.

The ops$ prefix is only needed when you want the user to be able to log into the operating system, then log into oracle with just a '/'. My comment about having your cake and eating it too was meant to indicate that you if you set up your ops$ account with a password, you can log in with a '/' from the operating system, and can log in using your password from the client. You do have to use the ops$ prefix when specifying your username from the client. An example in a previous posting showed how to create the ops$ account with the IDENTIFIED EXTERNALLY clause. If you do this, you cannot ever log into that account from a client.

You can use your procedure for handling the creation of the account, although you do have to specify an initial password. You would create the account with some password. Let the user know the account is created and have them contact you. You give them the initial password. They change it using the ALTER USER command.

I don't know if you are saying that you are trying to avoid having a client enter a password. If you are, I strongly disagree. You can set it up so that a client connects without a password to an ops$ account, but you have to have faith that the client's username has been validated correctly. I don't have that faith because it is very easy for a client to change their username. Received on Fri May 24 1996 - 00:00:00 CEST