On Mon, Dec 5, 2016 at 4:31 PM, Haribabu Kommi
wrote:
>
>
> On Mon, Oct 3, 2016 at 3:11 PM, Michael Paquier > wrote:
>
>> On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi
>> wrote:
>> > The above changes are based on my understanding to the discussion
>> occurred in
>> > this mail. In case if I
On Mon, Oct 3, 2016 at 3:11 PM, Michael Paquier
wrote:
> On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi
> wrote:
> > The above changes are based on my understanding to the discussion
> occurred in
> > this mail. In case if I miss anything, please let me know, i will
> > correct the same.
>
> Th
On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi
wrote:
> The above changes are based on my understanding to the discussion occurred in
> this mail. In case if I miss anything, please let me know, i will
> correct the same.
The patch series still apply.
+ " ((classid = (select o
On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane wrote:
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.
+1.
> In particular, the co
On 02/09/2016 01:22 PM, Tom Lane wrote:
> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet. But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that mak
* Joe Conway (m...@joeconway.com) wrote:
> On 02/09/2016 01:22 PM, Tom Lane wrote:
> > Maybe we need to restrict that somehow, or maybe some better solution
> > exists that we've not thought of yet. But in its current state, RLS
> > is at least as much a security hazard as it is a security aid.
>
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > Personally I don't buy that the current situation is a good thing. I
> > know that the "ship has sailed" and regret not having participated in
> > the earlier discussions, but I agree with JD here -- the unprivileged
> > user sh
Joe Conway writes:
> Personally I don't buy that the current situation is a good thing. I
> know that the "ship has sailed" and regret not having participated in
> the earlier discussions, but I agree with JD here -- the unprivileged
> user should not have to even think about whether RLS exists, t
On 9 February 2016 at 19:47, Robert Haas wrote:
> I think you're dismissing Tom's concerns far too lightly. The
> row_security=off mode, which is the default, becomes unusable for
> non-superusers under this proposal. That's bad. And if you switch to
> the other mode, then you might accidentall
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 9 February 2016 at 19:47, Robert Haas wrote:
> > I think you're dismissing Tom's concerns far too lightly. The
> > row_security=off mode, which is the default, becomes unusable for
> > non-superusers under this proposal. That's bad. And if y
On 02/09/2016 12:47 PM, Robert Haas wrote:
> On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote:
>> JD,
>>
>> * Joshua D. Drake (j...@commandprompt.com) wrote:
>>> pg_dump -U $non-super_user
>>>
>>> Should just work, period.
>>
>> That ship has sailed already, where you're running a pg_dump again
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake (j...@commandprompt.com) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed already, where you're running a pg_dump against
>
On 02/09/2016 12:28 PM, Stephen Frost wrote:
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
pg_dump -U $non-super_user
Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Just to be
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> > To the extent that untrusted code execution is an issue (and my
> > experience with environments which would deploy RLS tells me that it
> > isn't a practical concern), an option could be create
On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost wrote:
> JD,
>
> * Joshua D. Drake (j...@commandprompt.com) wrote:
>> pg_dump -U $non-super_user
>>
>> Should just work, period.
>
> That ship has sailed already, where you're running a pg_dump against
> objects you don't own and which have RLS enabled
On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost wrote:
> Arbitrary code execution is quite a different concern from the prior
> concern regarding incomplete dumps.
I've had both concerns all along, and I think I've mentioned them before.
> To the extent that untrusted code execution is an issue (a
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> pg_dump -U $non-super_user
>
> Should just work, period.
That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.
Thanks!
Stephen
signature.asc
Description: Digital s
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> > On 02/09/2016 11:47 AM, Robert Haas wrote:
> >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
> Whereupon you'd have no certainty that what you got represented a
> comp
On 02/09/2016 12:05 PM, Robert Haas wrote:
That's true. But I should also have an expectation that running
pg_dump won't trigger arbitrary code execution, which is why by
default, pg_dump sets row_security to OFF. That way, if a row
security policy applies, I get an error rather than an incomp
On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway wrote:
> On 02/09/2016 11:47 AM, Robert Haas wrote:
>> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
Whereupon you'd have no certainty that what you got represented a
complete dump of your own data.
>>>
>>> It would be a dump of what y
On 02/09/2016 11:47 AM, Robert Haas wrote:
> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
>>> Whereupon you'd have no certainty that what you got represented a
>>> complete dump of your own data.
>>
>> It would be a dump of what you're allowed to see, rather than an error
>> saying you c
On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost wrote:
>> Whereupon you'd have no certainty that what you got represented a
>> complete dump of your own data.
>
> It would be a dump of what you're allowed to see, rather than an error
> saying you couldn't dump something you couldn't see, which is
I've closed this as returned-with-feedback.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Stephen Frost writes:
> >>> I don't follow how this would destroy the ability to run pg_dump.
> >>> Ideally, we'd have a result where a user could run pg_dump without
> >>> having to app
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> I don't follow how this would destroy the ability to run pg_dump.
>>> Ideally, we'd have a result where a user could run pg_dump without
>>> having to apply any filters of their own and they'd get a dump o
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> However, by "not that much trouble" I only mean getting an implementation
> >> that works and doesn't create more security problems than it fixes.
> >> Usability is still likely to be a h
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> However, by "not that much trouble" I only mean getting an implementation
>> that works and doesn't create more security problems than it fixes.
>> Usability is still likely to be a huge problem. In particular it seems
>> likely th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > As Stephen mentioned, yes, I am very interested in at least some aspects
> > of this patch. The ability to apply RLS to system tables could be useful
> > to solve a number of problems we don't have a good story for today,
> > multi-te
Joe Conway writes:
> On 01/06/2016 12:15 PM, Robert Haas wrote:
>> Is any committer thinking about taking a serious look at this patch series?
>>
>> I ask because (1) it seems like it could be nice to have but (2) it
>> frightens me terribly. We are generally very sparing about assuming
>> that
On 01/06/2016 12:15 PM, Robert Haas wrote:
> On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
> wrote:
>> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
>> because 4_database_catalog_tenancy_v5 patch depends on it.
>>
>> Here I attached all the patches for your convenience, I am a
On Thu, Jan 7, 2016 at 2:29 PM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>
>> Apart from the issue of whether this is doomed for some architectural
>> reason, it is not entirely clear to me that there's any consensus that
>> we want this. I don't think that
On 2016/01/06 13:07, Haribabu Kommi wrote:
> On Wed, Jan 6, 2016 at 1:43 PM, Amit Langote
>>
>> Patch 4_database_catalog_tenancy_v5 fails to apply:
>
> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> because 4_database_catalog_tenancy_v5 patch depends on it.
Oops, I even missed
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
> wrote:
> > May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> > because 4_database_catalog_tenancy_v5 patch depends on it.
> >
> > Here I attached all the patches for your conv
On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi
wrote:
> May be you missed to apply the 3_shared_catalog_tenancy_v4 path,
> because 4_database_catalog_tenancy_v5 patch depends on it.
>
> Here I attached all the patches for your convenience, I am able to
> apply all patches in the order without any
On 2016/01/06 10:17, Haribabu Kommi wrote:
> On Mon, Jan 4, 2016 at 10:43 PM, Haribabu Kommi
>>
>> Thanks for the test. Yes, the issue happens at backend startup itself.
>> I will give a try by separating the initialization of security
>> policies after init phase 3.
>
> Here I attached updated pa
On Mon, Jan 4, 2016 at 8:34 PM, Amit Langote
wrote:
> On 2016/01/04 14:43, Haribabu Kommi wrote:
>>>
>>> Here I attached new series of patches with a slightly different approach.
>>> Instead of creating the policies on the system catalog tables whenever
>>> the catalog security command is executed
On 2016/01/04 14:43, Haribabu Kommi wrote:
>>
>> Here I attached new series of patches with a slightly different approach.
>> Instead of creating the policies on the system catalog tables whenever
>> the catalog security command is executed, just enable row level security
>> on the system catalog t
On Thu, Dec 17, 2015 at 12:46 PM, Haribabu Kommi
wrote:
> Rebased patch is attached as it is having an OID conflict with the
> latest set of changes
> in the master branch.
Here I attached new series of patches with a slightly different approach.
Instead of creating the policies on the system cat
Rebased patch is attached as it is having an OID conflict with the
latest set of changes
in the master branch.
Regards,
Hari Babu
Fujitsu Australia
4_database_catalog_tenancy_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Oct 21, 2015 at 2:42 PM, Haribabu Kommi
wrote:
> Pending items:
> 1. Need to add some more tests to verify all database catalog tables.
> 2. Documentation changes for database catalog tenancy.
Here I attached the updated database-catalog-security with more tests
including system views,
in
On Sat, Oct 10, 2015 at 1:54 AM, Stephen Frost wrote:
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> We've got one reloption for views already - security_barrier. Maybe
>> >> we
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> We've got one reloption for views already - security_barrier. Maybe
> >> we could have another one that effectively changes a particular
On 10/08/2015 11:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> We've got one reloption for views already - security_barrier. Maybe
>> we could have another one that effectively changes a particular view
>> from "security definer" as it is today to "security invoker"
On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> We've got one reloption for views already - security_barrier. Maybe
>> we could have another one that effectively changes a particular view
>> from "security definer" as it is today to "security
* Robert Haas (robertmh...@gmail.com) wrote:
> We've got one reloption for views already - security_barrier. Maybe
> we could have another one that effectively changes a particular view
> from "security definer" as it is today to "security invoker".
As I recall, there was a previous suggestion (h
On Tue, Oct 6, 2015 at 7:29 AM, Stephen Frost wrote:
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
>> wrote:
>> > Here I attached an updated version of the patch with the following changes.
>>
>> I found some problems related to providing
On Tue, Oct 6, 2015 at 10:29 PM, Stephen Frost wrote:
> * Haribabu Kommi (kommi.harib...@gmail.com) wrote:
>> On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
>> wrote:
>> > Here I attached an updated version of the patch with the following changes.
>>
>> I found some problems related to providing
* Haribabu Kommi (kommi.harib...@gmail.com) wrote:
> On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
> wrote:
> > Here I attached an updated version of the patch with the following changes.
>
> I found some problems related to providing multi-tenancy on a system
> catalog view.
> This is because,
On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
wrote:
> Here I attached an updated version of the patch with the following changes.
I found some problems related to providing multi-tenancy on a system
catalog view.
This is because, system catalog view uses the owner that is created
the user inst
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote:
> On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
>> If any user is granted any permissions on that object then that user
>> can view it's meta data of that object from the catalog tables.
>> To check the permissions of the user on the object, inste
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote:
> > Also, we've faced issues in the past with making catalog changes due to fear
> > of breaking user scripts. Instead of doubling down on that with RLS on top
> > of catalog tables, would it be better
On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote:
> Also, we've faced issues in the past with making catalog changes due to fear
> of breaking user scripts. Instead of doubling down on that with RLS on top
> of catalog tables, would it be better to move the tables to a different
> schema, make the
On 9/14/15 7:38 PM, Haribabu Kommi wrote:
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote:
On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
If any user is granted any permissions on that object then that user
can view it's meta data of that object from the catalog tables.
To check the permissio
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote:
> On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
>> If any user is granted any permissions on that object then that user
>> can view it's meta data of that object from the catalog tables.
>> To check the permissions of the user on the object, inste
On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
> If any user is granted any permissions on that object then that user
> can view it's meta data of that object from the catalog tables.
> To check the permissions of the user on the object, instead of
> checking each and every available option, I just
On Fri, Aug 14, 2015 at 12:00 PM, Haribabu Kommi
wrote:
>
> Here I attached the proof concept patch.
Here I attached an updated patch by adding policies to the most of the
system catalog tables, except the following.
AggregateRelationId
AccessMethodRelationId
AccessMethodOperatorRelationId
Acces
This is regarding supporting of multi-tenancy in a single PostgreSQL instance
using the row level security feature. The main idea is to have the
"row level security"
enabled on system catalog tables, thus the user can get only the rows that are
either system objects or the user objects, where the u
57 matches
Mail list logo
