On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug <fgp@phlo.org> wrote:
> On Oct20, 2011, at 01:19 , Tom Lane wrote:
>> Florian Pflug <fgp@phlo.org> writes:
>>> Taking this even further, why do we bother with non-immutable (i.e.,
>>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
>>> at all?
>>
>> Yeah, I was wondering about that one too. It would not solve all the
>> problems here, but skipping validity checks would fix some of them.
>> The trouble of course is what happens if the value is found to be bad
>> when you try to use it ...
>
> Presumably we'd detect that during logon, because the GUC assignment
> hook will quite probably complain. I'd vote for emitting a warning in
> that case. This is also what we due currently if we fail to set the
> GUC to the desired value due to permission issues
>
> postgres=# create role r1 login;
> CREATE ROLE
> postgres=# create role r2;
> CREATE ROLE
> postgres=# alter role r1 set role = r2;
> ALTER ROLE
> postgres=# \connect - r1
> WARNING: permission denied to set role "r2"
> WARNING: permission denied to set role "r2"
> You are now connected to database "postgres" as user "r1".
>
> (Dunno why that WARNING appears twice)
>
> Since an ALTER DATABASE/ROLE SET doesn't prevent the user from overriding
> the value, ignoring invalid settings shouldn't be a security risk.
I didn't realize these dependencies weren't immutable. If that is the
desired behavior, then I agree a warning should be sufficient to catch
typo's and oversights.
If you did want to make them immutable, I also like Florian's idea of
a dependency graph. This would make the dumps less readable though.
>
> best regards,
> Florian Pflug
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>