On 2014-03-12 20:54:36 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund
> > wrote:
> >> Except that we don't have the infrastructure to perform such checks
> >> (neither partial, nor expression indexes, no exclusion constraints) on
> >> system table
Robert Haas writes:
> On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund wrote:
>> Except that we don't have the infrastructure to perform such checks
>> (neither partial, nor expression indexes, no exclusion constraints) on
>> system tables atm. So it's not a entirely trivial thing to do.
> I'm pro
On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund wrote:
>> Isn't this just a case of creating a suitable operator and an exclusion
>> constraint? Defining the constraint in BKI might require extra
>> infrastructure, but it should be possible.
>
> Except that we don't have the infrastructure to perf
* Josh Berkus (j...@agliodbs.com) wrote:
> On 03/12/2014 11:25 AM, Stephen Frost wrote:
> > * Josh Berkus (j...@agliodbs.com) wrote:
> >> Local superusers (maybe this concept needs another name) would be able
> >> to do the following things in a *single* database:
> >>
> >> 1 change permissions for
On 03/12/2014 11:40 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 03/12/2014 02:09 PM, Josh Berkus wrote:
>>> Well, if you really want my "I want a pony" list:
>>>
>>> Local superusers (maybe this concept needs another name) would be able
>>> to do the following things in a *single* database:
Andrew Dunstan writes:
> On 03/12/2014 02:09 PM, Josh Berkus wrote:
>> Well, if you really want my "I want a pony" list:
>>
>> Local superusers (maybe this concept needs another name) would be able
>> to do the following things in a *single* database:
>>
>> 1 change permissions for other users o
On 03/12/2014 11:25 AM, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> Local superusers (maybe this concept needs another name) would be able
>> to do the following things in a *single* database:
>>
>> 1 change permissions for other users on that database and its objects
>
> Wh
* Josh Berkus (j...@agliodbs.com) wrote:
> Local superusers (maybe this concept needs another name) would be able
> to do the following things in a *single* database:
>
> 1 change permissions for other users on that database and its objects
What about "bypass" permissions, ala what superuser does
On 03/12/2014 02:09 PM, Josh Berkus wrote:
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
On Mar 12, 2014 1:46 AM, "Josh Berkus" wrote:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to put in the work
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
> On Mar 12, 2014 1:46 AM, "Josh Berkus" wrote:
>> Yeah, what we really need is encapsulated per-DB users and local
>> superusers. I think every agrees that this is the goal, but nobody
>> wants to put in the work to implement a generalized solution.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > You could COPY over the hba file or sometihng like that :) Or just
> > pg_read_binary_file() on the files in another database, which is accessible
> > through SQL as well.
>
> More directly, he could alter pg_authid to make him
Magnus Hagander writes:
> On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
>> A local user with the superuser privilege would not be able to log into
>> another database, because superuser doesn't give you any extra privilege
>> until you've logged in.
>>
>> Yeah, as superuser you could still br
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
> > I share your doubts as to how useful such a concept actually is, but
> > it'd work if we had real local users.
>
>
> It can also do interesting things like ALTER SYSTEM, replication, backups,
> e
On Wed, Mar 12, 2014 at 3:52 PM, Tom Lane wrote:
> Magnus Hagander writes:
> >> Yeah, what we really need is encapsulated per-DB users and local
> >> superusers. I think every agrees that this is the goal, but nobody
> >> wants to put in the work to implement a generalized solution.
>
> > Encap
Magnus Hagander writes:
>> Yeah, what we really need is encapsulated per-DB users and local
>> superusers. I think every agrees that this is the goal, but nobody
>> wants to put in the work to implement a generalized solution.
> Encapsulated would probably be the doable part. But local superuser
Jaime Casanova writes:
> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
>> But not sure how to define a unique
>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>> (joe, 0).
> and why you want that restriction?
So that if I say "GRANT SELECT ON mytable TO joe", it's una
On 2014-03-12 10:03:42 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Andrew Dunstan writes:
> > > On 03/11/2014 09:37 PM, Tom Lane wrote:
> > >> In particular, I'd like to see an exclusion that prevents local users
> > >> from having the same name as any global user, so that we don't have
> >
Tom Lane wrote:
> Andrew Dunstan writes:
> > On 03/11/2014 09:37 PM, Tom Lane wrote:
> >> In particular, I'd like to see an exclusion that prevents local users
> >> from having the same name as any global user, so that we don't have
> >> ambiguity in GRANT and similar commands. This doesn't seem
On Mar 12, 2014 1:46 AM, "Josh Berkus" wrote:
>
> On 03/11/2014 06:57 AM, Tom Lane wrote:
> > Mind you, I wouldn't be unhappy to see it go away; it's a kluge and
always
> > has been. I'm just expecting lots of push-back if we try. And it's
kind
> > of hard to resist push-back when you don't have
Andrew Dunstan wrote
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane <
> tgl@.pa
> > wrote:
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
>> and why you want that res
On Tue, Mar 11, 2014 at 10:52 PM, Andrew Dunstan wrote:
>
> On 03/11/2014 11:50 PM, Jaime Casanova wrote:
>>
>> On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
>>>
>>> But not sure how to define a unique
>>> index that allows (joe, db1) to coexist with (joe, db2) but not with
>>> (joe, 0).
>>>
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when you login you need to specify
the db, rig
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane wrote:
> But not sure how to define a unique
> index that allows (joe, db1) to coexist with (joe, db2) but not with
> (joe, 0).
>
and why you want that restriction? when you login you need to specify
the db, right? if you don't specify the db then is the
On 03/11/2014 11:06 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn
So I'll admit to using it, only in "toy" setups...
I use it with trust and ident, on local connections though, not password
I try to keep my laptops clean of mysqld, and I use PG. And only on my
laptop/PC, I make a database for every user... And every "app" get's a
userid, and a schema
Andrew Dunstan writes:
> On 03/11/2014 09:37 PM, Tom Lane wrote:
>> In particular, I'd like to see an exclusion that prevents local users
>> from having the same name as any global user, so that we don't have
>> ambiguity in GRANT and similar commands. This doesn't seem simple to
>> enforce (if w
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn't seem simple to
enforce (if we supported partial indexes on sy
On 03/11/2014 07:41 PM, Tom Lane wrote:
Andrew Dunstan writes:
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
Andrew Dunstan writes:
> 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
Josh Berkus writes:
> On 03/11/2014 06:57 AM, Tom Lane wrote:
>> Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
>> has been. I'm just expecting lots of push-back if we try. And it's kind
>> of hard to resist push-back when you don't have a substitute to offer.
> Yeah
On 03/11/2014 06:57 AM, Tom Lane wrote:
> Mind you, I wouldn't be unhappy to see it go away; it's a kluge and always
> has been. I'm just expecting lots of push-back if we try. And it's kind
> of hard to resist push-back when you don't have a substitute to offer.
Yeah, what we really need is enc
On 03/11/2014 12:37 PM, Stephen Frost wrote:
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
* Andrew Dunstan (and...@dunslane.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
On 03/11/2014 09:57 AM, Tom Lane wrote:
Magnus Hagander writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the fact that I have *never* come across i
Magnus Hagander writes:
> On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
>> Are you claiming there are no users, and if so, on what evidence?
> I am claiming that I don't think anybody is using that, yes.
> Based on the fact that I have *never* come across it on any system I've
> come across
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
> >> It will be 12 years this year since this "temporary measure" was
> >> added. I'm just wondering, is there any "complete solution" that
> >> anyone had in mind y
Magnus Hagander writes:
> On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
>> It will be 12 years this year since this "temporary measure" was
>> added. I'm just wondering, is there any "complete solution" that
>> anyone had in mind yet? Or should this just be deprecated?
> I'd say +1 to remo
On Sun, Mar 9, 2014 at 9:00 PM, Thom Brown wrote:
> Hi,
>
> I've noticed that "db_user_namespace" has had the following note
> attached to it since 2002:
>
> "This feature is intended as a temporary measure until a complete
> solution is found. At that time, this option will be removed."
>
> It w
Hi,
I've noticed that "db_user_namespace" has had the following note
attached to it since 2002:
"This feature is intended as a temporary measure until a complete
solution is found. At that time, this option will be removed."
It will be 12 years this year since this "temporary measure" was
added.
39 matches
Mail list logo
