(2014/01/21 18:18), Dean Rasheed wrote:
On 21 January 2014 01:09, KaiGai Kohei wrote:
(2014/01/13 22:53), Craig Ringer wrote:
On 01/09/2014 11:19 PM, Tom Lane wrote:
Dean Rasheed writes:
My first thought was that it should just preprocess any security
barrier quals in subquery_planner
(2014/01/22 1:37), Robert Haas wrote:
On Mon, Jan 20, 2014 at 11:23 PM, KaiGai Kohei wrote:
I briefly checked the patch. Most of lines are mechanical replacement
from LWLockId to LWLock *, and compiler didn't claim anything with
-Wall -Werror option.
My concern is around LWLockTr
(2014/01/21 11:44), Shigeru Hanada wrote:
Thanks for the comments.
2014/1/21 KaiGai Kohei :
In addition, an idea which I can't throw away is to assume that all
constraints defined on foreign tables as ASSERTIVE. Foreign tables
potentially have dangers to have "wrong" data by
0,7 @@ save_backend_variables(BackendParameters *param, Port
*port,
param->SpinlockSemaArray = SpinlockSemaArray;
#endif
param->LWLockArray = LWLockArray;
+ param->MainLWLockArray = MainLWLockArray;
param->ProcStructLock = ProcStructLock;
param->ProcGlobal = Pr
rtually ASSERTIVE (not enforcing). Should it also be noted
explicitly?
Backward compatibility
NOT NULL [ASSERTIVE] might be an option.
Thanks,
--
OSS Promotion Center / The PG-Strom Project
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
x27;m not sure if this is workable yet, and it creates ugly
pointer-based backrefs *up* the Query chain, making what was previously
a tree of Query* into a graph. That could get exciting, though there'd
never be any need for mutators to follow the parent query pointer so it
wouldn't make tree
(2011/01/27 22:26), Robert Haas wrote:
> 2011/1/27 KaiGai Kohei:
>> - Error messages become obtaining "%m", when the error was
>> originated from the libselinux interfaces. It will provides
>> DBA a hint why interactions with SELinux does not work well.
>
&g
(2011/01/27 0:25), Robert Haas wrote:
> 2011/1/25 KaiGai Kohei:
>> (2011/01/26 12:23), KaiGai Kohei wrote:
>>>>> Yikes. On further examination, exec_object_restorecon() is pretty
>>>>> bogus. Surely you need some calls to quote_literal_cstr() in there
>&
(2011/01/26 12:23), KaiGai Kohei wrote:
>>> Yikes. On further examination, exec_object_restorecon() is pretty
>>> bogus. Surely you need some calls to quote_literal_cstr() in there
>>> someplace.
>>
> Are you concerning about the object name being s
(2011/01/24 12:49), Robert Haas wrote:
> On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas wrote:
>> On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas wrote:
>>> 2011/1/21 KaiGai Kohei:
>>>> The attached patch is a revised version.
>>>
>>> I've commit
(2011/01/20 13:01), Robert Haas wrote:
> 2011/1/19 KaiGai Kohei:
>>> And how about adding a
>>> ProcessUtility_hook to trap evil non-DML statements that some
>>> nefarious user might issues?
>>>
>> It seems to me reasonable as long as the number of c
(2011/01/20 12:10), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> How about feasibility to merge this 4KL chunks during the rest of
>> 45 days? I think we should decide this general direction at first.
>
> I read through this code tonight and it looks pretty straightforwar
t) using security-id (oid)
which is a primary key pointing out a certain text data in catalog table.
It well reduced storage consumption and achieved good performance in
comparison operation.
One challenge was to reclaim orphan texts. In this case, we needed to
lock out a user table referencing
re functions, and adding a 'bool *didUpdate'
> argument to some lower-level functions. I'm not sure if passing back
> the status in a bool* is considered good style, but this way all the
> functions look consistent.
>
> Regards,
> Marti
>
--
KaiGai Kohei
--
instruction assumes your installation is under
the /usr/local/pgsql directory, and the database cluster is
in /usr/local/pgsql/data. Substitute your paths appropriately.
It seems to me natural rather than using `pg_config --sharedir`
instead. (we might need to care about installation path of the
people
this feature being worthful, so the contents tend to philosophical
things rather than actual specifications.
I also think wiki page allows us to brush up the documentation
rather than exchanging patches effectively. I'll set up a wiki page
that contains same contents with *.sgml file to revise documentation
stuff to be included into the *.sgml file finally. How about this idea?
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2011/01/06 14:28), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> The attached patch is the modular version of SE-PostgreSQL (take.2).
>
> I'm reading through the documentation and so far it looks pretty
> reasonable. But I have some questions and suggested changes, of
&
rio for us is nothing were progressed in spite of
large man-power to review and discuss.
It may be more productive to keep features to be committed on the
last CF as small as possible, such as hooks to support a part of DDL
permissions or pg_regress enhancement to run regression test.
Thanks,
--
Ka
(2010/12/30 9:34), Simon Riggs wrote:
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become
(2010/12/27 17:53), Simon Riggs wrote:
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say th
(2010/12/24 11:53), KaiGai Kohei wrote:
> There is one another issue to be discussed.
> We need a special form of regression test. Because SE-PostgreSQL
> makes access control decision based on security label of the peer
> process, we need to switch psql process during regression te
(2010/12/14 13:31), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:53), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
>>>> (2010/12/14 12:10), Robert Haas wrote:
>>>>> 2010/12/13 KaiGai Kohei:
>>>>>>
(2010/12/14 12:53), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> (2010/12/14 12:10), Robert Haas wrote:
>>> 2010/12/13 KaiGai Kohei:
>>>> The starter version is not intended to use in production system,
>>>
>>> Well, what's the point, then?
(2010/12/14 12:10), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>> The starter version is not intended to use in production system,
>
> Well, what's the point, then? I thought we had enough infrastructure
> in place at this point to build a simple system that, while i
(2010/12/14 10:41), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>>>> I counted number of lines of the sepgsql module that implement
>>>> only currently supported hooks. It has 3.2KL of code not.
>>>
>>> Uh, wow. That's rather surprising. I th
(2010/12/14 9:32), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei:
>>>> It is a good news for me also, because I didn't imagine SE-PostgreSQL
>>>> module getting upstreamed, even if contrib module.
>>>>
>>>> OK, I'll focus on the works to
(2010/12/14 1:03), Robert Haas wrote:
> On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Kohei wrote:
>> (2010/12/13 21:53), Robert Haas wrote:
>>> 2010/12/12 KaiGai Kohei:
>>>>
>>>> I'd like to see opinions what facilities should be developed
>>>&
(2010/12/13 21:53), Robert Haas wrote:
2010/12/12 KaiGai Kohei:
I'd like to see opinions what facilities should be developed
to the current v9.1 development cycle.
It seems to me that the next commit after the label-switcher-function
patch ought to be a contrib module that implements a
ols at the following commands quite easy. It is an idea
to put hooks that we can implement with little impact around the
existing codes.
- GRANT/REVOKE
- COMMENT ON
- SECURITY LABEL
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Thanks for your reviewing.
The attached patch is a revised version.
I don't have any objections to your comments.
(2010/12/07 4:38), Robert Haas wrote:
> 2010/11/25 KaiGai Kohei:
>> The attached patch is a revised one.
>>
>> It provides two hooks; the one informs co
ould try to tackle, is it?
Sorry, I don't have a credible idea to solve this inconsistency right now.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/11/29 10:43), Robert Haas wrote:
> 2010/11/28 KaiGai Kohei:
>>> I'm not totally convinced that this is the correct behavior. It seems
>>> a bit surprising that UPDATE privilege on a single column is enough to
>>> lock out all SELECT activity f
(2010/11/27 9:11), Robert Haas wrote:
> 2010/11/25 KaiGai Kohei:
>> (2010/10/16 4:49), Josh Kupershmidt wrote:
>>> [Moving to -hackers]
>>>
>>> On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs
>>> wrote:
>>>> On Mon, 2010-10-11 at 09:41 -040
(2010/11/26 11:35), Fujii Masao wrote:
On Thu, Nov 25, 2010 at 3:18 PM, KaiGai Kohei wrote:
The attached patch is revised version.
- Logging part within auth_delay was removed. This module now focuses on
injection of a few seconds delay on authentication failed.
- Documentation parts were
mand
seems to me odd.
I think this patch fixes the behavior as we expected.
BTW, how about backporting this patch?
It seems to me a bug fix, although it contains user visible changes.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/11/19 16:57), KaiGai Kohei wrote:
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
If we don't need a PoC module for
function individually.
Rest of parts are revised according to the comment.
I also fixed up source code comments which might become incorrect.
Thanks,
(2010/11/18 11:30), Robert Haas wrote:
> 2010/11/17 KaiGai Kohei:
>> I revised my patch as I attached.
>>
>> The hook fun
didn't put post-creation hook
on foreign data wrapper, foreign server and user mapping
exceptionally. So, I put this hook around their command
handler like any other object classes.
Thanks,
(2010/11/24 12:07), Robert Haas wrote:
> 2010/11/23 KaiGai Kohei:
>>> What
>>> I'
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.
>>
(2010/11/18 11:30), Robert Haas wrote:
> 2010/11/17 KaiGai Kohei:
>> I revised my patch as I attached.
>>
>> The hook function is modified and consolidated as follows:
>>
>> typedef enum FunctionCallEventType
>> {
>> FCET_BE_HOO
(2010/11/18 2:17), Robert Haas wrote:
On Wed, Nov 17, 2010 at 10:32 AM, Ross J. Reedstrom wrote:
On Tue, Nov 16, 2010 at 09:41:37PM -0500, Robert Haas wrote:
On Tue, Nov 16, 2010 at 8:15 PM, KaiGai Kohei wrote:
If we don't need a PoC module for each new hooks, I'm not strongly
mo
up regression test, dummy_seclabel module and its
documentation as Robert pointed out in another topic.
Thanks,
(2010/11/14 13:16), KaiGai Kohei wrote:
> (2010/11/14 11:19), Robert Haas wrote:
>> 2010/11/12 KaiGai Kohei:
>>> The attached patch allows the security label
sting.
I also note that the
patch offers the ability to log superuser logins. Since that seems a
bit off-topic for a contrib module called auth_delay, and since we
already have a GUC called log_connections, I'm inclined to propose
removing that part.
I agree with the suggestion.
Thanks,
(2010/11/14 11:19), Robert Haas wrote:
2010/11/12 KaiGai Kohei:
The attached patch allows the security label provider to switch
security label of the client during execution of certain functions.
I named it as "label switcher function"; also called as "trusted-
procedure"
d_label shall return NULL or a valid label
if the supplied function is a label switcher. It also informs
the PG core whether the function is switcher or not.
Thanks,
--
KaiGai Kohei
pgsql-switcher-function.1.patch
Description: application/octect-stream
--
Sent via pgsql-hackers mailing
(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:
>
dependency mechanism.
I believe it will be a clear guidance for the future maintenance works.
Thanks,
(2010/11/11 7:41), KaiGai Kohei wrote:
> (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:
>&
(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
any reason to restrict it to the set of objects to which it's sensible
to apply security labels.
Because I thought too many hooks within one patch gives burden to reviewers,
so I restricted it on a part of object classes in this version.
However,it is not a compelling reason.
OK, I'l
(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 &quo
eate() for aggregates/functions
- TypeCreate() and TypeShellMake() for types
- create_proc_lang() for procedural languages
- inv_create() for large objects
Thanks,
--
KaiGai Kohei
*** a/src/backend/catalog/heap.c
--- b/src/backend/catalog/heap.c
***
*** 61,66
--- 61,67
(2010/11/04 22:05), Itagaki Takahiro wrote:
2010/11/4 KaiGai Kohei:
The attached patch is a contrib module to inject a few seconds
delay on authentication failed. It is also a proof of the concept
using the new ClientAuthentication_hook.
This module provides a similar feature to pam_faildelay
authentication fails prevents (or makes hard at least) brute-force
attacks, because it limits number of candidates that attacker can
verify within a unit of time.
Thanks,
--
KaiGai Kohei
pgsql-v9.1-auth-delay.1.patch
Description: application/octect-stream
--
Sent via pgsql-hackers mailing list (pgsql
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
(2010/10/19 21:31), Robert Haas wrote:
On Oct 19, 2010, at 4:34 AM, KaiGai Kohei wrote:
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in thei
me
not impossible.
Well, I'd like to suggest to revise the specifications of permission
checks on these commands. If we can ensure these functions are not
malicious, no need to care about information leaks via untrusted
functions internally used.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers ma
yeballs than author of enhanced security modules.
So, I believe it eventually reduce burden to maintain, and enables to
overlook code-paths that bypass the upcoming DDL permission checks.
Anyway, let's have a discussion when we put security hooks for DDL checks.
But the next patch will fo
e trade-off, as earlier researcher
pointed out, but user can inform on which does he give higher priority.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/10/15 22:04), Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) 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.
>
>
-or-nothing. If we can plug most part of the threat with
reasonable performance degrading, it is worthwhile to fix up.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(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
(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
(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
ur task to
understand and maintain.
Thanks,
(2010/10/08 9:39), KaiGai Kohei wrote:
(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
(2010/10/12 3:34), Peter Eisentraut wrote:
> On tor, 2010-10-07 at 12:45 +0900, KaiGai Kohei wrote:
>> * The logic is still unclear for me.
>>
>> The check_hostname() immediately returns with false, if the resolved
>> remote hostname is NOT matched with the hostna
(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
(2010/10/06 10:21), KaiGai Kohei wrote:
> I'll check the patch for more details, please wait for a few days.
I could find out some matters in this patch, independent from the
discussion of localhost. (About pg_hba.conf.sample, I'm sorry for
the missuggestion. Please fix up it accor
haps people
>>> would like these functions to be consistent.
>>>
>> Tom Lane suggested to add missing_ok argument, although it is not a must-
>> requirement.
>
> Actually I think he suggested the opposite.
>
Ahh, I understood his suggestion as literal.
Well
(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() b
(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
(2010/10/06 4:41), Peter Eisentraut wrote:
> On tis, 2010-10-05 at 12:35 +0900, KaiGai Kohei wrote:
>> It seems to me this patch has been left for a long time, although it tries
>> to provide a useful functionality.
>>
>> In the previous discussion, several issues wer
ude.
The case 1 and 2 have differences from others. It allows to expose hidden
values, then people may be able to see these values without any inference.
So, their through-put is relatively faster than others. It means degree of
threat is also higher.
If we try to tacker to the matter 1 and 2, suggest
p here, because
no commercial RDBMSs with RLS don't handle such kind of side-channel
attacks using key conflicts.
And, it seems to me the cost will be too expensive to care about the
case (3) and (4). So, I think it is worthless to fix up them.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(2010/10/06 0:33), KaiGai Kohei wrote:
> (2010/10/05 23:56), Tom Lane wrote:
>> Robert Haas writes:
>>> Checking the functions of the operators is the right thing to do, but
>>> assuming that internal = safe does not work. For example, pushing
>>> down arit
ain criteria, maybe, 'safe' flag in
pg_proc.
In my opinion, I like to categorize error messages as side-channel,
because its through-put is much less than regular-channels, so scale
of the threat is relatively small.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing li
(2010/10/05 23:16), Robert Haas wrote:
2010/10/5 KaiGai Kohei:
The term "built-in functions" means functions written in INTERNAL language
here. But we also have SQL functions by default. Some of them are just a
wrapper to internal functions. I'm not sure the checking of INTERNAL
(2010/10/05 18:01), Itagaki Takahiro wrote:
> 2010/9/6 KaiGai Kohei:
>> The attached patch tackles both of the above two points, and allows to
>> control this deoptimization when CREATE SECURITY VIEW is used.
>
> I'll send a review for the patch.
>
Thanks fo
(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 appropria
ws is that I chose to remove the
> "missing_ok" argument from get_role_oid_or_public, so it's not a perfect
> mirror of it. None of the current callers need it, but perhaps people
> would like these functions to be consistent.
>
Tom Lane suggested to add mi
st of the times, which is a moderately common
> mistake. We already rely on localhost being (forward) resolvable for
> the stats collector.
>
> Something to think about: Maybe we need a quoting mechanism in case
> someone names their hosts "samenet".
>
>
>
>
(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 nu
(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_h
(2010/09/30 0:36), Robert Haas wrote:
> On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei wrote:
>> (2010/09/29 22:00), Robert Haas wrote:
>>>
>>> On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheiwrote:
>>>>
>>>> I don't think it is an op
(2010/09/29 22:00), Robert Haas wrote:
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei wrote:
I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull out any information about
the new relation from syscache.
Why not?
All the exi
(2010/09/29 20:53), Dave Page wrote:
2010/9/29 KaiGai Kohei:
Does the git.postgresql.org down?
Harada-san being also unreachable now.
Seems to be a network issue. It's fine for some people (like me), and
down for others.
Thom reports that it's now back for him.
Now I'm r
Does the git.postgresql.org down?
Harada-san being also unreachable now.
--
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks for your reviewing, and sorry for delayed responding due to
the LinuxCon Japan for a couple of days.
(2010/09/28 12:57), Robert Haas wrote:
2010/9/1 KaiGai Kohei:
This patch allows external security providers to check privileges
to create a new relation and to inform the security labels
(2010/09/27 11:49), Robert Haas wrote:
On Sat, Sep 25, 2010 at 7:04 AM, KaiGai Kohei wrote:
* The "dummy_esp" module and regression test for SECURITY LABEL statement.
This module allows only four labels: "unclassified", "classified",
"secret" and &
(2010/09/24 20:56), Robert Haas wrote:
2010/9/23 KaiGai Kohei:
Please see http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php
OK, I'll emulate this approach at first.
Don't worry about this part - I will do this myself. If you can just
fix the pg_dump stuff, I thi
where any backslash command
> is almost bound to be something not terribly mnemonic, and because
> there are likely to be either no security labels at all or so many
> that a command that just dumps them ALL out in bulk is all but
> useless. But we at least need to provide a suitable
(2010/09/24 11:53), Robert Haas wrote:
> 2010/9/23 KaiGai Kohei:
>>> Most of the contents of the new documentation section on external
>>> security providers seemed irrelevant to me, which I guess I can only
>>> blame myself for since I was the one who asked for that
Robert, thanks for your reviewing and revising.
(2010/09/23 13:28), Robert Haas wrote:
> On Thu, Sep 16, 2010 at 11:12 PM, Robert Haas wrote:
>> 2010/9/14 KaiGai Kohei:
>>> The attached patch is a revised version, but a bit difference from what
>>> I introduced ye
(2010/09/22 5:17), Peter Eisentraut wrote:
> On tis, 2010-09-21 at 17:53 +0900, KaiGai Kohei wrote:
>> Sorry, I missed a bug when we create a typed table using composite
>> type which has been altered.
>
>> Perhaps, we also need to patch at transformOfType() to
ugh CREATE TYPE prohibits to create
a composite type without any attribute.
What does it mean a composite type with no attribute?
Or, do we need a restriction to prevent the last one attribute?
Rest of comments are below.
(2010/09/18 5:44), Peter Eisentraut wrote:
> On fre, 2010-09-17 at 18:15
to me not difficult to alter columns of typed
tables subsequent with this ALTER TYPE, although it might be
not easy to alter definitions of embedded composite type already
in use.
Of course, it may be our future works. If so, it's good.
Thanks,
--
KaiGai Kohei
--
Sent via pgsql-hackers maili
(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Kohei:
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux
RITY LABEL statement, apart from whether
it manages the supplied security label, or not.
Thanks,
(2010/08/31 15:27), KaiGai Kohei wrote:
> The attached patch is a revised version of security label support.
>
> summary of changes:
> * The logic to translate object-name to object-id was r
(2010/09/02 13:30), KaiGai Kohei wrote:
> (2010/09/02 12:38), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei:
>>> (2010/09/02 11:57), Robert Haas wrote:
>>>> 2010/9/1 KaiGai Kohei:
>>>>> Right now, it stands on a strict assumption that considers operators
(2010/09/02 12:38), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> (2010/09/02 11:57), Robert Haas wrote:
>>> 2010/9/1 KaiGai Kohei:
>>>> Right now, it stands on a strict assumption that considers operators
>>>> implemented with built-in functions are saf
(2010/09/02 11:57), Robert Haas wrote:
> 2010/9/1 KaiGai Kohei:
>> Right now, it stands on a strict assumption that considers operators
>> implemented with built-in functions are safe; it does not have no
>> possibility to leak supplied arguments anywhere.
>>
>>
1 - 100 of 909 matches
Mail list logo
