>> (The NOCREATEUSER option used when creating the collective user does
>> prevent it from changing its own password via
>> ALTER USER guest WITH ... PASSWORD ...
>You think so?
>
>This approach is doomed to failure --- the system sees no reason not to
>allow a user to change his own configuration, including his password.
I stand corrected. The command
ALTER USER guest WITH ... PASSWORD ...
now fails under my experimental setup - but it's not due to the
NOCREATEUSER option used when creating the user guest. I haven't
figured out yet how I've finally managed to make it fail (I've lost
count of all the ruses I've tried). Yet in the worst case, I can use
a special PAM authentication method for the user in question - in
which case changing its password via ALTER USER will either fail or
be null and void. So the protection of the user guest's password from
user-made changes must allow for a documented solution.
As to whether this approach is doomed to failure, I'm sure that it
can succeed - the question is only the price. It may require a custom
version of PostgreSQL - either built from patched sources or using a
special loadable shared object (say, 'anon_ro_user.so') preloaded into
each postmaster through a line like
preload_libraries = '$libdir/anon_ro_user:anon_ro_user_init'
in postgresql.conf. It's a very steep price that I'd like to avoid,
though.
>Use more than one username.
Sorry, it's no option. I currently have about 700 users that could
potentially use the same account (associated with an application
through which solely these ~700 users connect to the database).
I must eliminate the administrative overhead of adding/deleting
these PostgreSQL users that shouldn't need to be declared in the
first place.
PS
My PostgreSQL version is 7.4.7.
Thanks,
-----------------------------------------------------------------------------
Alex Gutman, EMC Corp. :: Tel (877) 362-2887 ext. 44962 :: Fax (508) 435-8852
