and...@dunslane.net (Andrew Dunstan) writes:
> Jeff Davis wrote:
>> On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote:
>>
>>> I think it has to be looked at in comparison to more general
>>> prospective-permissions schemes;
>>
>> When I searched google for "prospective permissions", all I found we
* Andrew Dunstan [090630 09:08]:
>
>
> Aidan Van Dyk wrote:
>>
>> *especially* if those grants remain "by reference", i.e. If I change the
>> GRANTS/REVOKES on sensitive_table, those are automatically "apply" to all
>> tables created with the "WITH GRANTS LIKE sensitive_table"...
>>
>>
>>
>
> I
Aidan Van Dyk wrote:
*especially* if those grants remain "by reference", i.e. If I change the
GRANTS/REVOKES on sensitive_table, those are automatically "apply" to all
tables created with the "WITH GRANTS LIKE sensitive_table"...
Isn't that exactly what Tom is objecting to, namely that
* Greg Stark [090630 00:18]:
> Perhaps tieing it to the schema is wrong and we should actually
> require the user to specify the template they want explicitly which
> would be even better for that. So it would be something like "WITH
> GRANTS LIKE sensitive_table".
And, not having any experienc
On Tue, Jun 30, 2009 at 4:39 AM, Josh Berkus wrote:
>
>
>> Well I don't understand how you get them wrong if you're just pasting
>> them from a file. I mean, sure you can pick the wrong template but
>> nothing can help you there. You could just as easily pick the wrong
>> template if it's a databas
On Tue, Jun 30, 2009 at 04:24:40AM +0100, Greg Stark wrote:
> On Tue, Jun 30, 2009 at 1:51 AM, Josh Berkus wrote:
> >
> >> It does seems slightly silly since surely anyone creating a new
> >> object would just paste in their grants from another object or
> >> some common source anyways, but I suppo
Greg,
Well I don't understand how you get them wrong if you're just pasting
them from a file. I mean, sure you can pick the wrong template but
nothing can help you there. You could just as easily pick the wrong
template if it's a database feature instead of a text file.
I really have to wonder
On Tue, Jun 30, 2009 at 1:51 AM, Josh Berkus wrote:
>
>>It does
>> seems slightly silly since surely anyone creating a new object would
>> just paste in their grants from another object or some common source
>> anyways, but I suppose that's the way with convenience features.
>
> That works fine unt
Greg,
And there's "I just created a new table, I want "www" and
"www-backend" to get their usual privileges without thinking about it.
You want to be able to specify default grants that an object gets
based on the schema? That seems mostly reasonable though it might be a
good idea to have a WITH
On Mon, Jun 29, 2009 at 9:02 PM, Josh Berkus wrote:
> What I'm saying is that there are many users currently using schema for
> security classes. I personally haven't ever encountered a DBA who used role
> ownership of objects as a mechanism for security context. There's nothing
> conceptually in
Greg,
In particular, one early question was whether to use wildcard patterns
or schema names. People were saying wildcard patterns would be more
flexible because people don't always set up their objects in different
schemas. But if we had a mechanism someone wanted to use which
depended on schem
On Mon, Jun 29, 2009 at 7:41 PM, Josh Berkus wrote:
> The main reason is existing practice.
I haven't followed the entire conversation so i'm not sure who I'm
going to be disagreeing with or agreeing with here. But I wanted to
mention that existing practice may not be a very useful place to start
Tom,
From what I recall of prior discussions, there is rough consensus that
the two types of facilities you mentioned (setting up default ACLs to be
applied at creation of objects created later, and providing a way to
change multiple objects' permissions with one GRANT) are desirable,
though th
Josh Berkus writes:
> The second, and bigger problem I can see is that this opens a whole new
> set of security holes by allowing an end-run around the existing access
> control structure with attackers can try to exploit.
Yeah. I'm very concerned about any scheme that invents additional
sourc
Jeff,
I don't see why either of these things should be properties of the
schema. It seems to make much more sense for these defaults to be a
property of the user who creates the objects.
The main reason is existing practice. Currently, most applications I
see in the field which bother with h
Jeff Davis writes:
> On Mon, 2009-06-29 at 10:52 -0700, Josh Berkus wrote:
>> 1) ALTER SCHEMA SET DEFAULT PRIVILEGES statements which sets default
>> permissions, by ROLE and object type, on new objects.
>>
>> 2) a statement to set privs on all existing objects by type and role
>> within a sche
On Mon, 2009-06-29 at 10:52 -0700, Josh Berkus wrote:
> 1) ALTER SCHEMA SET DEFAULT PRIVILEGES statements which sets default
> permissions, by ROLE and object type, on new objects.
>
> 2) a statement to set privs on all existing objects by type and role
> within a schema.
I don't see why either
All,
First, let me talk about the problem: it's been my observation that the
majority of users, including public commercial web sites, which I run
into in the field do not employ permissions in any useful way to protect
their data. An awful lot of these applications are running as the
superu
Jeff Davis wrote:
On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote:
I think it has to be looked at in comparison to more general
prospective-permissions schemes;
When I searched google for "prospective permissions", all I found were
links to messages in this thread ;)
Can you refe
Jeff Davis writes:
> Can you refer me to a general prospective-permissions scheme that is
> more widely accepted?
Well, the point of my post was that nothing's gotten to the point of
being "widely accepted". But there are people working on a "default
ACLs" scheme that would cover some of that te
On Mon, 2009-06-29 at 12:55 -0400, Tom Lane wrote:
> I think it has to be looked at in comparison to more general
> prospective-permissions schemes;
When I searched google for "prospective permissions", all I found were
links to messages in this thread ;)
Can you refer me to a general prospectiv
Andrew Dunstan writes:
> David Fetter wrote:
>> There have been previous discussions of prospective permissions
>> changes. Are we restarting them here?
> It's not on the TODO list. I recall it being raised from time to time
> but I certainly don't recall a consensus that it should be done, nor
On Sun, Jun 28, 2009 at 06:28:32PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>> On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
>>
>>> David Fetter wrote:
>>>
> * Users who come from MySQL every once in a while, annoyed that
> we don't su
David Fetter wrote:
On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
* Users who come from MySQL every once in a while, annoyed that
we don't support "GRANT ... *" syntax.
I'm missing what's wrong with a wild-card GRANT syn
On Sun, 2009-06-28 at 18:03 -0400, Stephen Frost wrote:
> * David Fetter (da...@fetter.org) wrote:
> > On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
> > > Without a major change in the way we do permissions, it will not
> > > work prospectively. We have no way ATM to store permi
On Sun, 2009-06-28 at 14:38 -0700, David Fetter wrote:
> There have been previous discussions of prospective permissions
> changes. Are we restarting them here?
>
I don't remember seeing anything in those discussions that really
materialized. Can you point me to something that you think is a bet
On Sun, 2009-06-28 at 14:16 -0700, David Fetter wrote:
> > The users I'm targeting with my idea are: * Users who have a fairly
> > simple set of users and permissions, and who want a simple picture
> > of the permissions in their system for reassurance/verification.
>
> I don't know of a case that
* David Fetter (da...@fetter.org) wrote:
> On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
> > Without a major change in the way we do permissions, it will not
> > work prospectively. We have no way ATM to store permissions for an
> > object that does not currently exist.
>
> Th
On Sun, 2009-06-28 at 17:23 -0400, Robert Haas wrote:
> I do to some degree share Tom's worry that this is an idiosyncratic
> solution to a tiny subset of the problem space.
I share the concern. However, I don't know if it's a "tiny subset" or
not; I think we'll have to get some feedback from user
On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>>
>>> * Users who come from MySQL every once in a while, annoyed that
>>> we don't support "GRANT ... *" syntax.
>>>
>>
>> I'm missing what's wrong with a wild-card GRANT syntax for this
>> case.
>
David Fetter wrote:
* Users who come from MySQL every once in a while, annoyed that we
don't support "GRANT ... *" syntax.
I'm missing what's wrong with a wild-card GRANT syntax for this case.
Without a major change in the way we do permissions, it will not work
prospectively
On Sun, Jun 28, 2009 at 2:07 PM, Jeff Davis wrote:
> I'd like some brief feedback on this idea before I try to make a real
> proposal.
>
> The use case is this:
>
> You have an application with several roles:
> * admin user - owns all the objects related to that application
> * normal user - INSE
On Sun, Jun 28, 2009 at 12:52:54PM -0700, Jeff Davis wrote:
> On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote:
> > > I meant for "foo" to be a user. "foo_ro" would be the read-only
> > > version, who has a strict subset of foo's permissions.
> >
> > I see. It seems like rather a complicated (an
On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote:
> > I meant for "foo" to be a user. "foo_ro" would be the read-only version,
> > who has a strict subset of foo's permissions.
>
> I see. It seems like rather a complicated (and expensive) mechanism
> for a pretty narrow use-case. It'd only help
Jeff Davis writes:
> On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote:
>> Jeff Davis writes:
>>> My idea is to have a "GRANT mask":
>>> CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
>>
>> You haven't really explained what "foo" is here.
> I meant for "foo" to be a user.
On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > My idea is to have a "GRANT mask":
> > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
>
> You haven't really explained what "foo" is here. If it's a single
> object then I don't think this offers a
Jeff Davis writes:
> My idea is to have a "GRANT mask":
> CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
You haven't really explained what "foo" is here. If it's a single
object then I don't think this offers any leverage. If it's a
placeholder or class representative of
On Sun, 2009-06-28 at 14:12 -0400, Bill Moran wrote:
> It seems to me that you're duplicating the functionality that is already
> possible by using groups. i.e. grant the permissions to the group and
> add users to the group as appropriate.
Take the use case in my email. You would have to grant a
Jeff Davis wrote:
>
> I'd like some brief feedback on this idea before I try to make a real
> proposal.
>
> The use case is this:
>
> You have an application with several roles:
> * admin user - owns all the objects related to that application
> * normal user - INSERT/UPDATE/DELETE plus seque
I'd like some brief feedback on this idea before I try to make a real
proposal.
The use case is this:
You have an application with several roles:
* admin user - owns all the objects related to that application
* normal user - INSERT/UPDATE/DELETE plus sequence usage
* read-only user - for rep
40 matches
Mail list logo
