> In short, I don't see any value in a password lock option either.
It seems to me that if I can give a user 'read only' access to a database,
I should be able to give 'read only' access in every aspect, including
locking down the password.
> And ISTM anyplace that used it would be getting in the way of good
> password management practice. Users *should* be encouraged to change
> their own passwords, and to do so regularly.
No real argument there, but is an application a 'user' in the ordinary
sense of the word? Would you, as DBA, prefer a locked-down password or
one that you might have to change in dozens of locations?
It seems me that the underlying issue of how to authenticate access
from an 'outside' and compromiseable client may not be easily solveable.
Locking down the password falls under the category of 'damage control'.
('Inside' clients can be compromised too, of course.)
I'm not sure 'ident' solves the problem any better than an embedded password
does, and the documentation on ident raises this red flag:
This authentication method is therefore only appropriate for
closed networks where each client machine is under tight control
and where the database and system administrators operate in close
contact. In other words, you must trust the machine running the
ident server. Heed the warning:
The Identification Protocol is not intended as an authorization
or access control protocol. --RFC 1413
--
Mike Nolan
