On Mon, Aug 31, 2015 at 05:46:08PM -0400, Bruce Momjian wrote:
> On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> > > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > > >> ON DATABASE,
On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> Josh Berkus wrote:
> > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> > >> dumping them
On Thu, Jul 30, 2015 at 10:37:33PM -0400, Adam Brightwell wrote:
> On Thu, Jul 30, 2015 at 02:26:34PM -0400, Robert Haas wrote:
> >> 1. "pg_dumpall -g"
> >> 2. "pg_dump --create" per database
> >
> > Gah, OK, I see your point. But we better document this, because if
> > you need a PhD in PostgreSQ
>> 1. "pg_dumpall -g"
>> 2. "pg_dump --create" per database
>
> Gah, OK, I see your point. But we better document this, because if
> you need a PhD in PostgreSQL-ology to take a backup, we're not in a
> good place.
Agreed. Though, honestly, I find this to be a cumbersome approach. I
think it ju
On Thu, Jul 30, 2015 at 2:49 AM, Noah Misch wrote:
> What exact formula did you have in mind? It must not be merely
>
> 1. "pg_dumpall -g"
> 2. "pg_dump" (without --create) per database
>
> which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
>
> 1. "pg_dumpall -g"
> 2. Iss
Noah Misch wrote:
> What exact formula did you have in mind? It must not be merely
>
> 1. "pg_dumpall -g"
> 2. "pg_dump" (without --create) per database
>
> which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
>
> 1. "pg_dumpall -g"
> 2. Issue a handwritten CREATE DATABA
On Wed, Jul 29, 2015 at 10:50:53AM -0400, Robert Haas wrote:
> On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch wrote:
> > On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
> >> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> >> > Hm? Let me try again: If the admin does a ALTER DA
On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch wrote:
> On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
>> > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
>> > ... *before* restoring a backup and the bac
On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
> > ... *before* restoring a backup and the backup does contain a setting
> > for the same guc, but with
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
>> > On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
>> >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
>> >> > DBA creates
On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
> > On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> >> > DBA creates a database and sets some properties (security labels, gucs,
>
On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
> On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
>> > DBA creates a database and sets some properties (security labels, gucs,
>> > acls) on it. Then goes on to restore a backup. Unfort
Josh Berkus wrote:
> On 07/28/2015 11:58 AM, Robert Haas wrote:
> > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> >> dumping them in pg_dump --create, and in pg_dump -Fc .
> >>
> >> In practice I see zer
* Andres Freund ([email protected]) wrote:
> On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> > On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> > > DBA creates a database and sets some properties (security labels, gucs,
> > > acls) on it. Then goes on to restore a backup. Unfortunately
On 07/28/2015 11:58 AM, Robert Haas wrote:
> I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
>> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
>> dumping them in pg_dump --create, and in pg_dump -Fc .
>>
>> In practice I see zero real use of pg_dumpall withou
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> > DBA creates a database and sets some properties (security labels, gucs,
> > acls) on it. Then goes on to restore a backup. Unfortunately that backup
> > might, or might not, overwrite the p
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
>> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
>> >> Yes, I think we should make restoring the database's properties the
>> >> j
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> >> Yes, I think we should make restoring the database's properties the
> >> job of pg_dump and remove it completely from pg_dumpall, unles
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
> On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
>> Yes, I think we should make restoring the database's properties the
>> job of pg_dump and remove it completely from pg_dumpall, unless we can
>> find a case where that's really going to brea
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> Yes, I think we should make restoring the database's properties the
> job of pg_dump and remove it completely from pg_dumpall, unless we can
> find a case where that's really going to break things.
CREATE DATABASE blarg;
SECURITY LABEL ON blarg IS
* Robert Haas ([email protected]) wrote:
> On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote:
> > On 20 July 2015 at 01:18, Noah Misch wrote:
> >> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
> >>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> >>> > Andres Freund
On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote:
> On 20 July 2015 at 01:18, Noah Misch wrote:
>> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
>>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
>>> > Andres Freund wrote:
>>> > > One thing worth mentioning is that argua
On 20 July 2015 at 01:18, Noah Misch wrote:
> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
>> > Andres Freund wrote:
>> > > One thing worth mentioning is that arguably the problem is caused by the
>> > > fact that we're here
On Thu, Jul 23, 2015 at 12:14:14PM -0400, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
> wrote:
> >> I like Noah's proposal of having pg_dump --create reproduce all
> >> database-level state.
> >
> > Should it be enabled by default? If so, then wouldn't it make more
> >
On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
wrote:
>> I don't think there's any line near pg_dumpall. That tool seems to
>> have grown out of desperation without much actual design. I think it
>> makes more sense to plan around that's the best pg_dump behavior for the
>> various use cases.
> While I'd favor optional --no-create if we were designing fresh, it's not
> worth breaking user scripts by changing that now.
Agreed. So, --create would not be enabled by default.
>> How would this handle related global objects? It seems like this part
>> could get a little tricky.
>
> Like ro
On Wed, Jul 22, 2015 at 03:42:58PM -0400, Adam Brightwell wrote:
> > I like Noah's proposal of having pg_dump --create reproduce all
> > database-level state.
>
> Should it be enabled by default? If so, then wouldn't it make more
> sense to call it --no-create and do the opposite? So, --no-creat
On Wed, Jul 22, 2015 at 4:42 PM, Adam Brightwell <
[email protected]> wrote:
>
> [...]
>
> Also, I think this would potentially conflict with what Fabrízio is
> doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
> preferable solution.
>
> https://commitfest
> I don't think there's any line near pg_dumpall. That tool seems to
> have grown out of desperation without much actual design. I think it
> makes more sense to plan around that's the best pg_dump behavior for the
> various use cases.
Ok.
> I like Noah's proposal of having pg_dump --create rep
Noah Misch wrote:
> On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
> > I think that makes sense, but what about other DATABASE level info
> > such as COMMENT? Should that also be ignored by pg_dump as well? I'm
> > specifically thinking of the discussion from the following thre
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
> > Consistency with existing practice would indeed have pg_dump ignore
> > pg_shseclabel and have pg_dumpall reproduce its entries.
>
> I think that makes sense, but what about other DATABASE level info
> such as COMMENT? Should th
> Consistency with existing practice would indeed have pg_dump ignore
> pg_shseclabel and have pg_dumpall reproduce its entries.
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the di
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > One thing worth mentioning is that arguably the problem is caused by the
> > > fact that we're here emitting database level information in pg_dump,
> >
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > One thing worth mentioning is that arguably the problem is caused by the
> > fact that we're here emitting database level information in pg_dump,
> > normally only done for dumpall.
>
> ... the reason for which is proba
Andres Freund wrote:
> One thing worth mentioning is that arguably the problem is caused by the
> fact that we're here emitting database level information in pg_dump,
> normally only done for dumpall.
... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It m
On 2015-07-14 13:09:26 -0400, Adam Brightwell wrote:
> All,
>
> >> I won't have time to do anything about this anytime soon, but I think we
> >> should fix that at some point. Shall I put this on the todo? Or do we
> >> want to create an 'open items' page that's not major version specific?
> >
>
> That doesn't answer my question. I'm talking about a client and server
> running on the same system with SELinux MLS policy so that getpeercon
> will return the context of the client process unless it has explicitly
> sets the socket create context . So again will postgresql if the
> sepgsql modu
>> Cc: Robert Haas; Adam Brightwell; Andres Freund;
>> [email protected];
>> Alvaro Herrera
>> Subject: Re: [HACKERS] security labels on databases are bad for dump &
>> restore
>>
>> So if I label a table with an SELinux context and the
-
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Ted Toth
> Sent: Wednesday, July 15, 2015 2:59 AM
> To: Kohei KaiGai
> Cc: Robert Haas; Adam Brightwell; Andres Freund; [email protected];
> Alvaro Herrera
> Subje
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Ted
On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai wrote:
> 2015-07-15 2:39 GMT+09:00 Ted Toth :
>> That's e
2015-07-15 2:39 GMT+09:00 Ted Toth :
> That's exactly what I'm talking about like I said KaiGais branch was
> never merged into the mainline so I do not believe that it is used at
> all.
>
It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based sec
That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.
Ted
On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas wrote:
> On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
>> I'm sort of new to this so maybe I'm mis
On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
> I'm sort of new to this so maybe I'm missing something but since the
> sepgsql SELinux userspace object manager was never integrated into
> postgresql (AFAIK KaiGais branch was never merged into the mainline)
> who uses these labels? What use are
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?
Ted
On Tue, Jul 14, 2015 at 12:09 PM, Adam Brightw
All,
>> I won't have time to do anything about this anytime soon, but I think we
>> should fix that at some point. Shall I put this on the todo? Or do we
>> want to create an 'open items' page that's not major version specific?
>
> I think adding it to the TODO would be great.
I'd be willing to
On Fri, Jul 10, 2015 at 7:57 AM, Andres Freund wrote:
> pg_dump dumps security labels on databases. Which makes sense. The
> problem is that they're dumped including the database name.
>
> Which means that if you dump a database and restore it into a
> differently named one you'll either get a fai
Hi,
pg_dump dumps security labels on databases. Which makes sense. The
problem is that they're dumped including the database name.
Which means that if you dump a database and restore it into a
differently named one you'll either get a failure because the database
does not exist, or worse you'll u
Drew,
> IMHO this is nonintuitive, the intuitive behavior of a security_barrier
> view should be to forbid inserting rows that can’t appear in the view.
>
Isn't that what WITH CHECK OPTION is meant to accomplish?
-Adam
--
Adam Brightwell - [email protected]
Database E
Hi guys, I’m seeing some non-intuitive behavior with the new updateable
security barrier views in 9.4. Below is the behavior of 9.4b3:
> =# create table widget ( id integer);
> CREATE TABLE
> =# create view widget_sb WITH (security_barrier=true) AS SELECT * from widget
> where id = 22;
> CREATE
2011/7/2 Tom Lane :
> Kohei KaiGai writes:
>> The origin of matter is, as you mentioned, collation to be used for system
>> catalog scan when we reference it via syscache.
>> So, the following chunk should be added, as I did in the userspace access
>> vector patch - part.1.
>
>> @@ -934,8 +935,7
Kohei KaiGai writes:
> The origin of matter is, as you mentioned, collation to be used for system
> catalog scan when we reference it via syscache.
> So, the following chunk should be added, as I did in the userspace access
> vector patch - part.1.
> @@ -934,8 +935,7 @@ CatalogCacheInitializeCa
On 06/29/2011 05:34 PM, Joe Conway wrote:
> The third key passed to SearchSysCache is CStringGetTextDatum(provider).
> Ultimately FunctionCall2Coll gets called with collation == 0 and
> varstr_cmp fails due to the ambiguity.
>
> Is there something new that should be used in place of
> CStringGetTe
On 06/29/2011 04:18 PM, Joe Conway wrote:
> 1) COLLATE clause is a new feature in 9.1?
> 2) The doc search feature on postgresql.org does not search the 9.1
>documentation?
>
> I looked in the 9.1 docs in SQL Commands->SELECT and could find no
> reference to COLLATE. Can anyone point me to som
I signed up to do a review on $subject patch for the commitfest. In
order to do that, I want to get SELinux and contrib/sepgsql properly set
up so that I can test. I ran into a problem when trying to do:
cd contrib/sepgsql
make install (succeeds)
make installcheck
2010/11/25 KaiGai Kohei :
> The attached patch is a revised patch.
>
> - The utils/hooks.h was renamed to catalog/objectaccess.h
> - Numeric in the tail of InvokeObjectAccessHook0() has gone.
> - Fixed bug in ATExecAddColumn; it gave AttributeRelationId
> to the hook instead of RelationRelationId.
The attached patch is a revised patch.
- The utils/hooks.h was renamed to catalog/objectaccess.h
- Numeric in the tail of InvokeObjectAccessHook0() has gone.
- Fixed bug in ATExecAddColumn; it gave AttributeRelationId
to the hook instead of RelationRelationId.
In addition, I found that we didn'
2010/11/23 KaiGai Kohei :
>> What
>> I'm not quite sure about is where to put the definitions you've added
>> to a new file utils/hooks.h; I don't feel that's a very appropriate
>> location. It's tempting to put them in utils/acl.h just because this
>> is vaguely access-control related and that he
Thanks for your reviewing, and sorry for the late reply.
I've not been available for a few days.
(2010/11/22 12:11), Robert Haas wrote:
> 2010/11/12 KaiGai Kohei:
>> (2010/11/12 19:34), KaiGai Kohei wrote:
>>> I revised my patch according to the prior suggestions.
>>>
>> I'm sorry. I revised my pa
2010/11/12 KaiGai Kohei :
> (2010/11/12 19:34), KaiGai Kohei wrote:
>> I revised my patch according to the prior suggestions.
>>
> I'm sorry. I revised my patch, but not attached.
>
> Please see this attached one.
I'm satisfied with this approach, although I intend to change
InvokeObjectAccessHook
(2010/11/12 19:34), KaiGai Kohei wrote:
> I revised my patch according to the prior suggestions.
>
I'm sorry. I revised my patch, but not attached.
Please see this attached one.
Thanks,
> Invocation of the hooks is encapsulated within macro, not function:
>
>+ #define InvokeObjectAccessHoo
I revised my patch according to the prior suggestions.
Invocation of the hooks is encapsulated within macro, not function:
+ #define InvokeObjectAccessHook0(access,classId,objectId,subId)\
+ do {\
+ if (object_a
(2010/11/11 3:00), Robert Haas wrote:
On Wed, Nov 10, 2010 at 8:33 AM, KaiGai Kohei wrote:
(2010/11/10 13:06), Robert Haas wrote:
In this patch, we put InvokeObjectAccessHook0 on the following functions.
- heap_create_with_catalog() for relations/attributes
- ATExecAddColumn() for attributes
On Wed, Nov 10, 2010 at 8:33 AM, KaiGai Kohei wrote:
> (2010/11/10 13:06), Robert Haas wrote:
>>>
>>> In this patch, we put InvokeObjectAccessHook0 on the following functions.
>>>
>>> - heap_create_with_catalog() for relations/attributes
>>> - ATExecAddColumn() for attributes
>>> - NamespaceCreate
(2010/11/10 13:06), Robert Haas wrote:
In this patch, we put InvokeObjectAccessHook0 on the following functions.
- heap_create_with_catalog() for relations/attributes
- ATExecAddColumn() for attributes
- NamespaceCreate() for schemas
- ProcedureCreate() for aggregates/functions
- TypeCreate() an
2010/11/9 KaiGai Kohei :
> The attached patch provides plugin modules a hook just after object
> creation time. In typical use cases, it enables to assign default
> security labels on object creation by the external security providers.
>
> As Robert suggested before, it provides a generic purpose m
2010/11/9 KaiGai Kohei :
> The attached patch provides plugin modules a hook just after object
> creation time. In typical use cases, it enables to assign default
> security labels on object creation by the external security providers.
It looks like "DDL Trigger" on other database products.
Do we
(2010/11/09 20:34), Itagaki Takahiro wrote:
2010/11/9 KaiGai Kohei:
The attached patch provides plugin modules a hook just after object
creation time. In typical use cases, it enables to assign default
security labels on object creation by the external security providers.
It looks like "DDL Tr
The attached patch provides plugin modules a hook just after object
creation time. In typical use cases, it enables to assign default
security labels on object creation by the external security providers.
As Robert suggested before, it provides a generic purpose main hook.
It takes an enum of Obje
On Mon, Oct 25, 2010 at 9:45 PM, Robert Haas wrote:
> Oh. You know, I am realizing that I misread this patch. This hook is
> actually after authentication has been done; it's merely before we've
> told the client what happened. So maybe this is committable as-is,
> modulo some work on the comme
On Tue, Oct 26, 2010 at 2:20 PM, Peter Eisentraut wrote:
> Isn't this error message logically backwards?
>
> =# SECURITY LABEL ON SCHEMA public IS NULL;
> ERROR: 22023: security label providers have been loaded
Ouch. How embarrassing. Fixed.
--
Robert Haas
EnterpriseDB: http://www.enterprise
Isn't this error message logically backwards?
=# SECURITY LABEL ON SCHEMA public IS NULL;
ERROR: 22023: security label providers have been loaded
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
On Mon, 25 Oct 2010 21:45:23 -0400
Robert Haas wrote:
> On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei wrote:
> > One possible candidate is CheckMyDatabase() that checks ACL_CONNECT
> > permission for the required database prior to execution of all the
> > queries.
> > Currently, we don't have an
On Mon, Oct 25, 2010 at 8:51 AM, KaiGai Kohei wrote:
> One possible candidate is CheckMyDatabase() that checks ACL_CONNECT
> permission for the required database prior to execution of all the
> queries.
> Currently, we don't have any security hook around here.
> But, if we have "InvokeSecurityHook
Sorry for this late responding. I got a cold later half of the last week.
(2010/10/20 12:10), Robert Haas wrote:
On Wed, Oct 13, 2010 at 2:13 AM, Robert Haas wrote:
2010/8/24 KaiGai Kohei:
I tried to revise the patch. It allows plugins to get control next to
client authentication, but before
On Wed, Oct 13, 2010 at 2:13 AM, Robert Haas wrote:
> 2010/8/24 KaiGai Kohei :
>> I tried to revise the patch. It allows plugins to get control next to
>> client authentication, but before returning the status to users.
>>
>> This change enables plugins which should be invoked on authentication
>>
(2010/10/18 23:14), Robert Haas wrote:
>> If MVCC visibility always would match with existing permission checks,
>> we don't need to pay special attention for these things, do we?
>
> It seems to me that you're worrying about the wrong set of problems.
> The original purpose of what I proposed was
2010/10/17 KaiGai Kohei :
> (2010/10/15 22:04), Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei ([email protected]) wrote:
>>> However, it requires the plugin modules need to know everything;
>>> such as what is visible/invisible. It seems to me too closely-
>>> coupled interface.
>>
>> I ag
(2010/10/15 22:04), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei ([email protected]) wrote:
>> However, it requires the plugin modules need to know everything;
>> such as what is visible/invisible. It seems to me too closely-
>> coupled interface.
>
> I agree with Robert on this one. We'r
KaiGai,
* KaiGai Kohei ([email protected]) wrote:
> However, it requires the plugin modules need to know everything;
> such as what is visible/invisible. It seems to me too closely-
> coupled interface.
I agree with Robert on this one. We're not trying to design a wholly
independent security m
2010/8/24 KaiGai Kohei :
> I tried to revise the patch. It allows plugins to get control next to
> client authentication, but before returning the status to users.
>
> This change enables plugins which should be invoked on authentication
> failed to utilize this hook, not only assignment of session
Robert Haas wrote:
> On Tue, Sep 28, 2010 at 3:57 AM, Shigeru HANADA
> wrote:
> > On Mon, 27 Sep 2010 21:07:33 -0400
> > Robert Haas wrote:
> >> I found and fixed a few more issues and committed this. ?The pg_dump
> >> support had a few escaping bugs, and I added tab completion support
> >> for p
(2010/10/12 23:09), Robert Haas wrote:
> On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei wrote:
>> As I introduced before, the idea of two hooks makes obvious where
>> we should put the security hooks; it is next to the existing DAC
>> checking. It is the best guideline, even if we will touch the co
On Tue, Oct 12, 2010 at 9:20 AM, KaiGai Kohei wrote:
> As I introduced before, the idea of two hooks makes obvious where
> we should put the security hooks; it is next to the existing DAC
> checking. It is the best guideline, even if we will touch the code
> around object creation in the future ve
(2010/10/12 20:59), Robert Haas wrote:
2010/10/11 KaiGai Kohei:
It enables us to put security hooks independent from MVCC visibility of
the new database object. If we pay attention for visibility of new database
object, it seems to me amount of things to understand and maintain will be
increased
2010/10/11 KaiGai Kohei :
> It enables us to put security hooks independent from MVCC visibility of
> the new database object. If we pay attention for visibility of new database
> object, it seems to me amount of things to understand and maintain will be
> increased, although MVCC visibility is fun
(2010/10/12 11:35), Robert Haas wrote:
> On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
>> It seems to me the conclusion of this discussion is unclear.
>>
>> We commonly try to find out an approach that minimize code complexity
>> to understand and maintain, so the point of issue is clear, b
On Mon, Oct 11, 2010 at 9:58 PM, KaiGai Kohei wrote:
> It seems to me the conclusion of this discussion is unclear.
>
> We commonly try to find out an approach that minimize code complexity
> to understand and maintain, so the point of issue is clear, but we
> still don't reach same conclusion, be
It seems to me the conclusion of this discussion is unclear.
We commonly try to find out an approach that minimize code complexity
to understand and maintain, so the point of issue is clear, but we
still don't reach same conclusion, because both of two ideas have merits
and demerits each other.
(2010/10/08 0:21), Robert Haas wrote:
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type,
On Wed, Oct 6, 2010 at 5:21 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
>> 2010/10/5 KaiGai Kohei :
>
>> > However, we also have a few headache cases.
>> > DefineType() creates a new type object and its array type, but it does not
>> > call Co
(2010/10/07 6:21), Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei:
However, we also have a few headache cases.
DefineType() creates a new type object and its array type, but it does not
call CommandCounterIncrement() by the
(2010/10/07 6:02), Robert Haas wrote:
> 2010/10/5 KaiGai Kohei:
>> I began to revise the security hooks, but I could find a few cases that does
>> not work with the approach of post-creation security hooks.
>> If we try to fix up the core PG routine to become suitable for the
>> post-creation
>> s
Excerpts from Robert Haas's message of mié oct 06 17:02:22 -0400 2010:
> 2010/10/5 KaiGai Kohei :
> > However, we also have a few headache cases.
> > DefineType() creates a new type object and its array type, but it does not
> > call CommandCounterIncrement() by the end of this function, so the ne
2010/10/5 KaiGai Kohei :
> I began to revise the security hooks, but I could find a few cases that does
> not work with the approach of post-creation security hooks.
> If we try to fix up the core PG routine to become suitable for the
> post-creation
> security hooks, it shall need to put more Com
(2010/10/01 11:23), Robert Haas wrote:
> On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
>> (2010/10/01 3:09), Robert Haas wrote:
>>> 2010/9/29 KaiGai Kohei:
In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the hook, rather than
a un
On Sep 30, 2010, at 9:01 PM, KaiGai Kohei wrote:
> (2010/10/01 3:09), Robert Haas wrote:
>> 2010/9/29 KaiGai Kohei:
>>> In addition, I want to give these entrypoints its name which
>>> represents an appropriate purpose of the hook, rather than
>>> a uniformed one.
>>
>> It sounds like you're prop
(2010/10/01 3:09), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>> In addition, I want to give these entrypoints its name which
>> represents an appropriate purpose of the hook, rather than
>> a uniformed one.
>
> It sounds like you're proposing to create a vast number of hooks
> rather than just
2010/9/29 KaiGai Kohei :
> In addition, I want to give these entrypoints its name which
> represents an appropriate purpose of the hook, rather than
> a uniformed one.
It sounds like you're proposing to create a vast number of hooks
rather than just one. If we have ~20 object types in the system,
(2010/09/30 10:28), Robert Haas wrote:
> 2010/9/29 KaiGai Kohei:
>>> But with that exception,
>>> they seemed to think that coarse-grained permissions would be fine for
>>> a basic implementation: perhaps even just install something in
>>> ProcessUtility_hook and bounce DDL across the board, so lon
2010/9/29 KaiGai Kohei :
>> But with that exception,
>> they seemed to think that coarse-grained permissions would be fine for
>> a basic implementation: perhaps even just install something in
>> ProcessUtility_hook and bounce DDL across the board, so long as it's
>> controlled by reference to the
1 - 100 of 337 matches
Mail list logo
