Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] DefaultACLs

From: Petr Jelinek <pjmodos(at)pjmodos(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Jan Urban'ski <wulczer(at)wulczer(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] DefaultACLs
Date: 2009-09-29 15:43:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane napsal(a):
> Petr Jelinek <pjmodos(at)pjmodos(dot)net> writes:
>> That's how it works now actually, the problem is that when you grant 
>> something in the chain you can't revoke it anywhere else in the chain 
>> when you are merging privileges as you proposed.
> To allow that, you have to have some notion of a priority order among
> the available defaults, so that you can sensibly say that A should
> override B.  Which is easy as long as they've got hierarchical scopes,
> but that doesn't seem like a restriction that will hold good for future
> extensions.

I am aware, I knew all that has been said so far at the time I sent in 
the patch actually. That's why I am very skeptical about having those 
future non-hierarchical filters, I just don't see a way to make it happen.
Also when you go to some insane complexity of default privileges that 
don't respect your database structure then you either want to handle it 
programatically as Josh said or you want to create new subroles what 
have create something privilege and different default privileges instead 
of hoping that the database will somehow magically do the right thing 
about default acls conflicts.

Petr Jelinek (PJMODOS)

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-09-29 15:48:29
Subject: Re: Using results from INSERT ... RETURNING
Previous:From: Andrew DunstanDate: 2009-09-29 15:35:15
Subject: Re: navigation menu for documents

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group