Re: Preventing changes to default settings of a collective account?

>> (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