On Fri, Sep 2, 2011 at 12:38 PM, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
I've committed this, but I still think it would be helpful to revise
that comment. The turn boosted up is not very precise or
informative. Could you submit a separate, comment-only patch to
improve this?
I tried
On 2011-09-06 04:55, Robert Haas wrote:
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havingayebhavi...@gmail.com wrote:
I didn't see my name as one
On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Pity we can't use git notes.
Well, I guess there's no law that says we can't. Should I give it a try?
I don't see why not :-) (But my guess is that you're going to need to
publish some pull and push
On 09/06/2011 09:35 AM, Robert Haas wrote:
[git notes is more than cumbersome ]
As much as I'd like to have something like this, I'm inclined to think
that it will take a whole lot more time to get this facility working
than it's really worth. Unless someone has a strong opinion the other
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Pity we can't use git notes.
I spent some time looking at this this morning, and my reaction is
yaggh!!
Yeah, we had this same discussion six weeks ago.
On Tue, Sep 6, 2011 at 4:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Pity we can't use git notes.
I spent some time looking at this this morning, and my reaction is
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've committed this, but I still think it would be helpful to revise
that comment. The turn boosted up is not very precise or
informative. Could you submit a separate, comment-only patch to
improve this?
I didn't see my name as one of
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've committed this, but I still think it would be helpful to revise
that comment. The turn boosted up is not very precise or
informative. Could you submit a
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've committed this, but I still think it would be helpful to revise
that comment. The
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga yebhavi...@gmail.com wrote:
On 2011-09-01 14:40, Robert Haas wrote:
userspace avc.
I've
Excerpts from Robert Haas's message of lun sep 05 23:55:33 -0300 2011:
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011:
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga yebhavi...@gmail.com
I've committed this, but I still think it would be helpful to revise
that comment. The turn boosted up is not very precise or
informative. Could you submit a separate, comment-only patch to
improve this?
I tried to put more detailed explanation about the logic of do { ... } while
loop of
On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Yes. It also caches an expected security label when a client being
labeled as scontext tries to execute a procedure being labeled as
tcontext, to reduce number of system call invocations on fmgr_hook
and needs_fmgr_hook.
On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Yes. It also caches an expected security label when a client being
labeled as scontext tries to execute a procedure being labeled as
tcontext, to reduce number of system call invocations on fmgr_hook
and
Robert, Thanks for your reviewing.
For me, the line you removed from dml.out causes the regression tests to fail.
Fixed. Why did I removed this line??
I don't understand what this is going for:
+ /*
+ * To boost up trusted procedure checks on db_procedure object
+ *
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, what is the current status of this patch?
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is suitable mechanism for security labels.
Sorry it's taken me a while to get around to
2011/8/18 Robert Haas robertmh...@gmail.com:
On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai kohei.kai...@emea.nec.com
wrote:
That's lame. I think we need to patch contrib/sepgsql so that it
fails to build in that case, rather than building and then not
working.
It might be the following
: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas robertmh...@gmail.com wrote:
[more problems]
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses which, and a Fedora 15 minimal install doesn't
include that. I
Kohei KaiGai kai...@kaigai.gr.jp writes:
2011/8/18 Robert Haas robertmh...@gmail.com:
Actually, as I look at this more, I think this build system is
completely mis-designed. Given that you want to build sepgsql,
selinux is not an optional feature. So the stuff in
contrib/sepgsql/Makefile
On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei KaiGai kai...@kaigai.gr.jp writes:
2011/8/18 Robert Haas robertmh...@gmail.com:
Actually, as I look at this more, I think this build system is
completely mis-designed. Given that you want to build sepgsql,
selinux is
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This patch seems unnecessary to me.
Hmm. I see now that it's parallel, but I find it pretty confusing
that building sepgsql without specifying --with-selinux results in a
shared
On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Why not just:
SHLIB_LINK = -lselinux
I wouldn't have any particular objection to that (although I think it's
supposed to be += here).
Oh, right.
I don't see that any of the other changes
Kaigai proposed are helpful,
On Fri, Aug 19, 2011 at 10:31 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Why not just:
SHLIB_LINK = -lselinux
I wouldn't have any particular objection to that (although I think it's
supposed to be += here).
Oh, right.
Robert Haas robertmh...@gmail.com writes:
On further review, if the initial configure was done without
--with-libxml, xml2 is doomed anyway.
True, but it's still possible to build a shlib that will then not work.
I just did, after manually supplying the right -I switch:
make
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: 19. August 2011 15:55
To: Tom Lane
Cc: Kohei KaiGai; Kohei Kaigai; Yeb Havinga; PgHacker
Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
On Fri, Aug 19, 2011 at 10:31 AM, Robert Haas
On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On further review, if the initial configure was done without
--with-libxml, xml2 is doomed anyway.
True, but it's still possible to build a shlib that will then not work.
I just
Kohei Kaigai kohei.kai...@emea.nec.com writes:
One point I'm worrying about is a case when contrib/sepgsql is compiled
with older libselinux than minimum requirement. In this case, we may not
notice the broken module unless user tries to load it actually.
Is there a good idea to ensure compile
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
No objection to fixing or backpatching this, but I'm not seeing the
argument for treating this module differently from contrib/xml2.
Because I screwed it up accidentally for sepgsql,
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 19. August 2011 16:34
To: Kohei Kaigai
Cc: Robert Haas; Kohei KaiGai; Yeb Havinga; PgHacker
Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
Kohei Kaigai kohei.kai...@emea.nec.com writes
Kohei Kaigai kohei.kai...@emea.nec.com writes:
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Well, they should get at least a warning from referencing undefined
functions, no?
Yes. User should notice warning messages due to undefined symbols.
I'm not certain whether it makes sense to add
On Fri, Aug 19, 2011 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei Kaigai kohei.kai...@emea.nec.com writes:
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Well, they should get at least a warning from referencing undefined
functions, no?
Yes. User should notice warning messages due to
On Fri, Aug 19, 2011 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane t...@sss.pgh.pa.us wrote:
No objection to fixing or backpatching this, but I'm not seeing the
argument for treating this module differently
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- char *ucontext of avc_cache was replaced by bool tcontext_is_valid.
- Comments added onto
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com
wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- char *ucontext of
On Thu, Aug 18, 2011 at 12:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com
wrote:
The attached patch is revised userspace-avc patch.
List of
. August 2011 17:53
To: Kohei Kaigai
Cc: Yeb Havinga; PgHacker; Kohei KaiGai
Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai kohei.kai...@emea.nec.com
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas robertmh...@gmail.com wrote:
[more problems]
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses which, and a Fedora 15 minimal install doesn't
include that. I fixed that by installing which, but maybe we ought
to be looking for
Havinga; PgHacker; Kohei KaiGai
Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas robertmh...@gmail.com wrote:
[more problems]
OK, I'm giving up for now. I hit two more snags:
1. chkselinuxenv uses which, and a Fedora 15
On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai kohei.kai...@emea.nec.com wrote:
That's lame. I think we need to patch contrib/sepgsql so that it
fails to build in that case, rather than building and then not
working.
It might be the following fix, but I have no idea to generate an error when
BTW, what is the current status of this patch?
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is suitable mechanism for security labels.
Thanks,
2011/7/22 Kohei KaiGai kai...@kaigai.gr.jp:
2011/7/22 Yeb Havinga yebhavi...@gmail.com:
On 2011-07-22 11:55,
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, what is the current status of this patch?
I think it's waiting for me to get around to reviewing it. Sorry,
been busy :-(
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is
2011/8/5 Robert Haas robertmh...@gmail.com:
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, what is the current status of this patch?
I think it's waiting for me to get around to reviewing it. Sorry,
been busy :-(
Thanks for your efforts.
The status of
-Original Message-
From: Yeb Havinga [mailto:yebhavi...@gmail.com]
Sent: 22. Juli 2011 10:23
To: Kohei Kaigai
Cc: Robert Haas; PgHacker; Kohei KaiGai
Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
On 2011-07-21 11:29, Kohei Kaigai wrote:
The attached patch
On 2011-07-22 11:55, Kohei Kaigai wrote:
2) Also I thought if it could work to not remember tcontext is valid, but
instead remember the consequence,
which is that it is replaced by unlabeled. It makes the avc_cache struct
shorter and the code somewhat
simpler.
Here is a reason why we hold
2011/7/22 Yeb Havinga yebhavi...@gmail.com:
On 2011-07-22 11:55, Kohei Kaigai wrote:
2) Also I thought if it could work to not remember tcontext is valid, but
instead remember the consequence,
which is that it is replaced by unlabeled. It makes the avc_cache
struct shorter and the code
On 2011-07-21 11:29, Kohei Kaigai wrote:
The attached patch is revised userspace-avc patch.
List of updates:
- The GUC of sepgsql.avc_threshold was removed.
- char *ucontext of avc_cache was replaced by bool tcontext_is_valid.
- Comments added onto static variables
- Comments of
On 2011-07-21 00:08, Robert Haas wrote:
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kohei Kaigaikohei.kai...@emea.nec.com writes:
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Is there a way to dump syscache statistics like there is for
MemoryContext..Stats (something - gdb helped me there)?
I don't know of one.
Besides that I have to admit having problems understanding why the 5MB cache
for
On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havingayebhavi...@gmail.com wrote:
Besides that I have to admit having problems understanding why the 5MB cache
for pg_seclabel is a problem; it's memory consumption is lineair only to the
size of the underlying
On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with standard
configurations, but that's also true for e.g. the block size.
Not really.
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with
standard configurations, but that's also true for e.g. the block size.
Also, the tests I did with varying bucket sizes suggested that
decreasing the syscache to
2011/7/21 Yeb Havinga yebhavi...@gmail.com:
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with standard
configurations, but that's also true for e.g. the block size.
Also, the tests I did with varying bucket sizes
2011/7/21 Robert Haas robertmh...@gmail.com:
On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga yebhavi...@gmail.com wrote:
Is it possible to only include the syscache on --enable-selinux
configurations? It would imply physical data incompatibility with standard
configurations, but that's also true
2011/7/19 Yeb Havinga yebhavi...@gmail.com:
On 2011-07-19 22:39, Heikki Linnakangas wrote:
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So,
On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga yebhavi...@gmail.com wrote:
* I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
gain and also backend process memory increase as indicated by KaiGai-san.
The vmsize without the patch increases from running restorecon 3864kB,
On 2011-07-20 16:54, Robert Haas wrote:
As to the first point, the other big problem with adding a syscache
here is that it could get really big. I've worried about that issue
previously, and Yev's perplexity about where the memory is going is
not too reassuring.
Yeah I just realized that
Yeb, Thanks for your volunteering.
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call
On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
kohei.kai...@emea.nec.com wrote:
The sepgsql_restorecon(NULL) assigns default security label on all the
database objects being controlled, thus, its workload caches security
label (including text data) of these objects.
So, ~5MB of difference is
On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
kohei.kai...@emea.nec.com wrote:
One question is why InitCatalogCache() should be invoked from InitPostgres()?
If we initialize syscache on starting up postmaster process, I think
all the syscache buckets will be ready on child process forks, and
On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
kohei.kai...@emea.nec.com wrote:
One question is why InitCatalogCache() should be invoked from
InitPostgres()?
If we initialize syscache on starting up postmaster process, I think
all the syscache buckets will be ready on child process
On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
kohei.kai...@emea.nec.com wrote:
The sepgsql_restorecon(NULL) assigns default security label on all the
database objects being controlled, thus, its workload caches security
label (including text data) of these objects.
So, ~5MB of
On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga yebhavi...@gmail.com wrote:
* I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
gain and also backend process memory increase as indicated by KaiGai-san.
The vmsize without the patch increases from running restorecon
Kaigai,
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries on growing up too large.
Should I move this patch to the next CF?
--
Josh Berkus
PostgreSQL Experts
On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus j...@agliodbs.com wrote:
Kaigai,
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries on growing up too large.
Should I
On Wed, Jul 20, 2011 at 4:19 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus j...@agliodbs.com wrote:
Kaigai,
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never
Kohei Kaigai kohei.kai...@emea.nec.com writes:
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries on growing up too large.
There used to be support for limiting the
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kohei Kaigai kohei.kai...@emea.nec.com writes:
I'd like to have a discussion about syscache towards next commit-fest.
The issues may be:
- Initial bucket allocation on most cases never be referenced.
- Reclaim cache entries
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora 15, instead.
Installing right now, thanks for the heads up!
/etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid
object
type db_blobs
It is not an error, but just a notification to inform users that
sepgsql_contexts
file contains invalid lines. It is harmless, so we can ignore them.
I don't think sepgsql.sgml should mention
On 2011-07-19 12:10, Kohei Kaigai wrote:
See the attached patch, that contains other 3 documentation updates.
I looked at the patch and the additions look good, though I didn't
actually apply it yet.
thanks
Yeb
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is Fedora 15, instead.
Installing right now, thanks for
On 2011-07-19 22:39, Heikki Linnakangas wrote:
On 19.07.2011 12:28, Yeb Havinga wrote:
On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (libselinux-2.0.99 or later).
My recommendation is
Hello KaiGai-san,
I've been preparing to review this patch by reading both pgsql-hackers
history on sepgsql, and also the RHEL 6 guide on SELinux this weekend,
today I installed GIT HEAD with --with-selinux on Scientific Linux 6,
developer installation, so far almost everything looking good.
Yeb, Thanks for your volunteering.
2011/7/18 Yeb Havinga yebhavi...@gmail.com:
Hello KaiGai-san,
I've been preparing to review this patch by reading both pgsql-hackers
history on sepgsql, and also the RHEL 6 guide on SELinux this weekend, today
I installed GIT HEAD with --with-selinux on
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
3) sepgsql is currently a bit hard to find in the documentation.
www.postgresql.org website search doesn't find sepgsql and selinux only
refers to an old PostgreSQL redhat bug in 2005 on bugzilla.redhat.com. I had
to
2011/7/18 Robert Haas robertmh...@gmail.com:
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
3) sepgsql is currently a bit hard to find in the documentation.
www.postgresql.org website search doesn't find sepgsql and selinux only
refers to an old PostgreSQL redhat bug
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So,
The attached patch re-defines pg_seclabel.provider as NameData, instead of Text,
and revert changes of catcache.c about collations; to keep consistency with the
security label support on shared objects.
All the format changes are hidden by (Get|Set)SecurityLabel(), so no
need to change
on the
On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
For syscache, length of a typical security label in selinux is
less than 64 bytes. If we assume an entry consume 128bytes
including Oid pairs or pointers, its consumption is 128KBytes
per 1,000 of tables or others.
(Do
2011/6/13 Robert Haas robertmh...@gmail.com:
On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
For syscache, length of a typical security label in selinux is
less than 64 bytes. If we assume an entry consume 128bytes
including Oid pairs or pointers, its consumption is
On Thu, Jun 9, 2011 at 3:09 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
Here is two level lookups.
The first is from object identifiers to security label; it can be boosted
using syscache mechanism. The second is from security labels to
access control decision; it can be boosted using
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
reference security label of the object using syscache interface.
I believe we decided
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
reference security label of the object using syscache interface.
Perhaps I'm missing it, but.. why is this necessary
2011/6/9 Robert Haas robertmh...@gmail.com:
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
reference security label of the object using
2011/6/9 Stephen Frost sfr...@snowman.net:
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
reference security label of the object using syscache interface.
Perhaps
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/9 Robert Haas robertmh...@gmail.com:
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog.
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/9 Stephen Frost sfr...@snowman.net:
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enables to
2011/6/9 Robert Haas robertmh...@gmail.com:
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/9 Robert Haas robertmh...@gmail.com:
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The only modification by this patch to the core routine is a
2011/6/9 Robert Haas robertmh...@gmail.com:
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/9 Stephen Frost sfr...@snowman.net:
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel
90 matches
Mail list logo
