On Fri, Sep 2, 2011 at 12:38 PM, Kohei Kaigai 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 to put more
On Tue, Sep 6, 2011 at 4:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
>> 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 si
Robert Haas writes:
> On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
> 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.
http://archives.postgresql.org/pgsql-hackers/2
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
w
On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera
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 instructions, because I g
On 2011-09-06 04:55, Robert Haas wrote:
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
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 wrote:
I didn't see my name as one of the reviewers in the commit message. If tha
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
> 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 wrote:
> >> > On 2011-09-01 14:40, Robert H
On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera
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 wrote:
>> > On 2011-09-01 14:40, Robert Haas wrote:
>> >>
>> >> userspace avc.
>> >> I've committed this, but I still thi
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 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 "
On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga 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 separate, co
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
> 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
loo
> On Fri, Aug 26, 2011 at 5:32 AM, Kohei KaiGai 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 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.
> If the exp
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 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 looking at this.
On Fri, Aug 19, 2011 at 11:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane 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 a
On Fri, Aug 19, 2011 at 11:46 AM, Tom Lane wrote:
> Kohei Kaigai 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 cer
Kohei Kaigai 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 -Werror here, or not.
H
> -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 w
Robert Haas writes:
> On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane 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, and I can't screw it
> up for xml
Kohei Kaigai 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 failure when we try t
On Fri, Aug 19, 2011 at 11:26 AM, Tom Lane wrote:
> Robert Haas 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 r
> -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,
Robert Haas 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 PROFILE=-I/usr/include/libxml2
Now ad
On Fri, Aug 19, 2011 at 10:31 AM, Robert Haas wrote:
> On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane 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 a
On Fri, Aug 19, 2011 at 10:20 AM, Tom Lane 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, though.
I w
Robert Haas writes:
> On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane 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 library that seems to compile OK but
On Fri, Aug 19, 2011 at 9:59 AM, Tom Lane wrote:
> Kohei KaiGai writes:
>> 2011/8/18 Robert Haas :
>>> 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
>>> co
Kohei KaiGai writes:
> 2011/8/18 Robert Haas :
>> 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 that is intended to link against l
efix=/usr/local/sepgsql instead?
>
> Thanks,
> --
> NEC Europe Ltd, SAP Global Competence Center
> KaiGai Kohei
>
>
>> -Original Message-
>> From: Robert Haas [mailto:robertmh...@gmail.com]
>> Sent: 18. August 2011 18:22
>> To: Kohei Kaigai
>>
2011/8/18 Robert Haas :
> On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai
> 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 genera
On Thu, Aug 18, 2011 at 1:17 PM, Kohei Kaigai 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
> $(with_selinux
ence Center
KaiGai Kohei
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 18. August 2011 18:22
> To: Kohei Kaigai
> Cc: Yeb Havinga; PgHacker; Kohei KaiGai
> Subject: Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache
>
> On
On Thu, Aug 18, 2011 at 1:00 PM, Robert Haas 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 a way to eliminat
om]
> Sent: 18. 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 wrote:
> > On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
&g
On Thu, Aug 18, 2011 at 12:52 PM, Robert Haas wrote:
> On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
>> On Thu, Jul 21, 2011 at 5:29 AM, Kohei Kaigai
>> wrote:
>>> The attached patch is revised userspace-avc patch.
>>>
>>> List of updates:
>>> - The GUC of sepgsql.avc_threshold was remov
On Thu, Aug 18, 2011 at 12:46 PM, Robert Haas wrote:
> On Thu, Jul 21, 2011 at 5:29 AM, 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 t
On Thu, Jul 21, 2011 at 5:29 AM, 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
> -
2011/8/5 Robert Haas :
> On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai 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 contrib/sepgsql part is unclear for
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai 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 suitable mechani
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 :
> 2011/7/22 Yeb Havinga :
>> On 2011-07-22 11:55, Kohei Kaigai wrote:
>>>
2) Also
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 sepgsql_avc_
2011/7/22 Yeb Havinga :
> 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
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
> -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, Koh
2011/7/21 Robert Haas :
> On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga 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 re
2011/7/21 Yeb Havinga :
>
>> 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
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 2
On Thu, Jul 21, 2011 at 3:25 PM, Yeb Havinga 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. SECURITY LABEL is suppose
On 2011-07-21 15:03, Robert Haas wrote:
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga 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 database. (in contrast wi
On Thu, Jul 21, 2011 at 4:00 AM, Yeb Havinga 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 pg_seclabel is a
On 2011-07-21 00:08, Robert Haas wrote:
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
Kohei Kaigai 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
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
> Kohei Kaigai 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
Kohei Kaigai 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 number of entries in a
On Wed, Jul 20, 2011 at 4:19 PM, Robert Haas wrote:
> On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus 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.
>>> - Recl
On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus 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 move
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 9:47 AM, Yeb Havinga 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, with
> > th
> On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
> 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 an upper li
> On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
> 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
> > unuse
On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
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
> unused syscache does n
On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
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 an upper limit of sysca
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 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 #buck
On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga 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, with
> the patch is
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, I
2011/7/19 Yeb Havinga :
> 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-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 Fedora
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 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 ch
> >> /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
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/con
2011/7/18 Robert Haas :
> On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai 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.
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai 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 manually remembe
Yeb, Thanks for your volunteering.
2011/7/18 Yeb Havinga :
> 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,
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.
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, I
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 patch
2011/6/13 Robert Haas :
> On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai 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
On Mon, Jun 13, 2011 at 7:51 AM, Kohei KaiGai 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 we have a way to
On Thu, Jun 9, 2011 at 3:09 PM, Kohei KaiGai 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 userspace avc.
OK. Let
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
>> 2011/6/9 Stephen Frost :
>>> * 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 :
> On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
>> 2011/6/9 Robert Haas :
>>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai wrote:
The only modification by this patch to the core routine is a new
syscache for pg_seclabel system catalog. The SECLABELOID enabl
On Thu, Jun 9, 2011 at 12:54 PM, Kohei KaiGai wrote:
> 2011/6/9 Stephen Frost :
>> * 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 o
On Thu, Jun 9, 2011 at 12:39 PM, Kohei KaiGai wrote:
> 2011/6/9 Robert Haas :
>> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai 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
2011/6/9 Stephen Frost :
> * 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 missi
2011/6/9 Robert Haas :
> On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai 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
* 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 necessar
On Thu, Jun 9, 2011 at 3:59 AM, Kohei KaiGai 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 against that previou
The attached patch adds contrib/sepgsql a cache mechanism for access
control decision of SELinux. It shall reduce the total number of
system call invocations to improve the performance on its access
controls.
In the current implementation, the sepgsql always raises a query to
SELinux in-kernel. Ho
91 matches
Mail list logo
