On 6/7/13 12:57 PM, Tom Lane wrote:
> Hm. Throwing a NOTICE saying "btw, this won't be of any value until the
> user has CREATE rights in that schema" might be a reasonable compromise.
Seems like a can of worms to me. There are many other cases where you
need to do something else in order to mak
>> Agreed.
>
> Seems reasonable.
Yy!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 07, 2013 at 02:49:37PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, Jun 07, 2013 at 12:26:59PM -0400, Tom Lane wrote:
> >> Essentially the argument for allowing this without a permissions check
> >> is "I'm not really doing anything to the schema, just preconfiguring the
> >
Noah Misch writes:
> On Fri, Jun 07, 2013 at 12:26:59PM -0400, Tom Lane wrote:
>> Essentially the argument for allowing this without a permissions check
>> is "I'm not really doing anything to the schema, just preconfiguring the
>> rights that will be attached to a new object if I later (successfu
On Fri, Jun 07, 2013 at 12:26:59PM -0400, Tom Lane wrote:
> I wrote:
> > Noah Misch writes:
> >> The particular restriction at hand, namely that a role have CREATE rights
> >> on a
> >> schema before assigning role-specific default privileges, seems like
> >> needless
> >> paternalism. It would
On Fri, Jun 7, 2013 at 12:44 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Essentially the argument for allowing this without a permissions check
>> is "I'm not really doing anything to the schema, just preconfiguring the
>> rights that will be attached to a new object if I
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Hm. Throwing a NOTICE saying "btw, this won't be of any value until the
> user has CREATE rights in that schema" might be a reasonable compromise.
Yeah, a NOTICE makes more sense than a WARNING, so +1 from me.
Thanks,
Stephen
si
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Essentially the argument for allowing this without a permissions check
>> is "I'm not really doing anything to the schema, just preconfiguring the
>> rights that will be attached to a new object if I later (successfully)
>> create o
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Essentially the argument for allowing this without a permissions check
> is "I'm not really doing anything to the schema, just preconfiguring the
> rights that will be attached to a new object if I later (successfully)
> create one in this schema".
Makes se
I wrote:
> Noah Misch writes:
>> The particular restriction at hand, namely that a role have CREATE rights on
>> a
>> schema before assigning role-specific default privileges, seems like needless
>> paternalism. It would be akin to forbidding ALTER ROLE ... PASSWORD on a
>> NOLOGIN role. I'd su
> Hm. I defended that restriction earlier, but it now occurs to me to
> wonder if it doesn't create a dump/reload sequencing hazard. I don't
> recall that pg_dump is aware of any particular constraints on the order
> in which it dumps privilege-grant commands. If it gets this right,
> that's mo
Noah Misch writes:
> The particular restriction at hand, namely that a role have CREATE rights on a
> schema before assigning role-specific default privileges, seems like needless
> paternalism. It would be akin to forbidding ALTER ROLE ... PASSWORD on a
> NOLOGIN role. I'd support removing it w
On Mon, Apr 29, 2013 at 01:25:47PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > On 04/29/2013 09:59 AM, Tom Lane wrote:
> >> As I pointed out to you last night, it does already say that.
> >> I think the problem here is that we're just throwing a generic
> >> permissions failure rather than id
Tom,
I'm also seeing that the DEFAULT PRIVs I get seem to be dependant on my
login role, not my current role. That is, if role "dba" has default
privs set, and role "josh", which is a member of "dba" does not, and
"josh" does "set role dba" before creating some tables, those tables do
NOT get dba
> Right. I wonder if there's any good reason why we shouldn't extend
> aclerror() to, in all cases, add a DETAIL line along the lines of
>
> ERROR: permission denied for schema web
> DETAIL: This operation requires role X to have privilege Y.
>
> Is there any scenario where this'd
Josh Berkus writes:
> On 04/29/2013 09:59 AM, Tom Lane wrote:
>> As I pointed out to you last night, it does already say that.
>> I think the problem here is that we're just throwing a generic
>> permissions failure rather than identifying the particular permission
>> needed.
> Yeah, a better err
On 04/29/2013 09:59 AM, Tom Lane wrote:
> Josh Berkus writes:
>> This moves the general brokenness of this feature from a bug to (a) a
>> documentation issue and (b) unusably fussy. For (a), I think we need
>> the following line in the docs:
>
>> DEFAULT PRIVILEGES may only be granted to a ROLE
Josh Berkus writes:
> This moves the general brokenness of this feature from a bug to (a) a
> documentation issue and (b) unusably fussy. For (a), I think we need
> the following line in the docs:
> DEFAULT PRIVILEGES may only be granted to a ROLE which already has
> CREATE permission on the spe
> rhaas=# create user bob;
> CREATE ROLE
> rhaas=# create schema we_like_bob;
> CREATE SCHEMA
> rhaas=# alter default privileges for role bob in schema we_like_bob
> grant select on tables to bob;
> ERROR: permission denied for schema we_like_bob
> rhaas=# grant create on schema we_like_bob to bo
On Sun, Apr 28, 2013 at 9:39 PM, Josh Berkus wrote:
>> The fine manual notes that the target role has to already have CREATE
>> privileges on the target schema --- maybe that's what's biting you in
>> this case?
>
> Nope. That was the first thing I thought of. It really is that the
> target role
> The fine manual notes that the target role has to already have CREATE
> privileges on the target schema --- maybe that's what's biting you in
> this case?
Nope. That was the first thing I thought of. It really is that the
target role must *own* the schema. So clearly a bug.
--
Josh Berkus
Josh Berkus writes:
> Actually, the problem is worse than I thought. It looks like I can't
> set default privs for any role which is not the owner of the schema:
> analytics2=> ALTER DEFAULT PRIVILEGES IN SCHEMA web GRANT SELECT ON
> TABLES TO dbreader;
> ERROR: permission denied for schema web
> ... in fact, there is no combination of actions which will make "FOR
> ROLE" work. Any invokation of "FOR ROLE" inevitably results in a
> "permission denied" message:
>
> analytics2=> \c - webui
> You are now connected to database "analytics2" as user "webui".
> analytics2=> ALTER DEFAULT PRIV
Folks,
The "FOR ROLE" syntax is completely broken, as of 9.2.4. Not sure when
exactly this got broken; I remember it working sometime in the past:
[jberkus@pgx-test ~]$ psql -U postgres analytics2
psql (9.2.4)
Type "help" for help.
analytics2=# ALTER DEFAULT PRIVILEGES FOR ROLE webui IN SCHEMA
24 matches
Mail list logo
