Re: db_user_namespace a "temporary measure"

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> Or we try to make it work. I don't think the idea is inherently bad,
> and I know there are people (like ISPs) who would like to have it
> work properly. Maybe in these days when most people are on dedicated
> VMs this matters less, but I don't think shared database servers are
> totally dead yet.

Agreed. There are certainly pretty big hosting companies out there
which are already doing multi-tenant PG, but they're using their own
approaches instead of anything we provide (because what we provide
sucks, basically..).

> The docs say:
>
> db_user_namespace causes the client's and server's user name
> representation to differ. Authentication checks are always done with
> the server's user name so authentication methods must be configured
> for the server's user name, not the client's. Because md5 uses the
> user name as salt on both the client and server, md5 cannot be used
> with db_user_namespace.
>
> Is that the only major issue? Why not have the server strip out the
> @db part if this is on? If we made this an initdb-time setting
> rather than a GUC then we'd remove the problems caused by turning
> this on and off. I'm not sure what other problems that might cause,
> but it doesn't seem totally intractable at first glance.

Isn't the other issue for ISPs essentially that we don't have row-level
security for our global catalogs? as in- we can't limit what's in
pg_authid to only those entries a given user should be able to see? I
don't think db_user_namespace addresses that issue (but I didn't go look
either).

Thanks,

Stephen