(2009/12/12 6:27), Robert Treat wrote:
>> One point. I'd like to introduce a use case without row-level granularity.
>>
>> The page.24 in this slide:
>>http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf
>>
>> shows SELinux performs as a logical wall between virtual domains in
>
(2009/12/12 21:51), Robert Haas wrote:
2009/12/12 KaiGai Kohei:
I'd like to summary about the framework.
I am not necessarily in agreement with many of the points listed in
this email.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities.
(2009/12/12 15:42), "Ing . Marcos Lui's Orti'z Valmaseda" wrote:
> KaiGai Kohei escribio':
>> Stephen Frost wrote:
>>
>>> Josh,
>>>
>>> * Joshua Brindle (met...@manicmethod.com) wrote:
>>>
Stephen Frost wrote:
> I do think that, technically, there's no reason we couldn't allow for
>>>
2009/12/12 KaiGai Kohei :
> I'd like to summary about the framework.
I am not necessarily in agreement with many of the points listed in
this email.
> * Functionalities
>
> The ACE framework hosts both of the default PG checks and upcoming
> enhanced securities. We can build a binary with multipl
KaiGai Kohei escribio':
> Stephen Frost wrote:
>
>> Josh,
>>
>> * Joshua Brindle (met...@manicmethod.com) wrote:
>>
>>> Stephen Frost wrote:
>>>
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and b
I'd like to summary about the framework.
* Functionalities
The ACE framework hosts both of the default PG checks and upcoming
enhanced securities. We can build a binary with multiple enhanced
security features, but user can choose one from them at most due
to the security label management.
So, i
Stephen Frost wrote:
> Josh,
>
> * Joshua Brindle (met...@manicmethod.com) wrote:
>> Stephen Frost wrote:
>>> I do think that, technically, there's no reason we couldn't allow for
>>> multiple "only-more-restrictive" models to be enabled and built in a
>>> single binary for systems which support i
Stephen Frost wrote:
>> In my cosmetic preference, "ace_" is better than "ac_". The 'e' means
>> extendable, and "ace" feels like something cool. :-)
>
> No complaints here.. I just hope this doesn't end up being *exactly*
> the same as your original PGACE patches.. I'd feel terrible if we
> wer
On Thursday 10 December 2009 21:47:18 KaiGai Kohei wrote:
> Greg Smith wrote:
> > It's funny; we started out this CommitFest with me scrambling to find
> > someone, anyone, willing to review the latest SE-PostgreSQL patch,
> > knowing it was a big job and few were likely to volunteer. Then
> > sch
Josh,
* Joshua Brindle (met...@manicmethod.com) wrote:
> Stephen Frost wrote:
>> I do think that, technically, there's no reason we couldn't allow for
>> multiple "only-more-restrictive" models to be enabled and built in a
>> single binary for systems which support it. As such, I would make those
Stephen Frost wrote:
KaiGai,
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and built in a
single binary for systems which support it. As such, I would make those
just "#if defined()" rather than "#elif". Let it be
On Fri, 2009-12-11 at 11:36 -0500, Stephen Frost wrote:
[Snip...]
>
> > In addition, OS allows to choose one enhanced security at most eventually.
> >
> > In my image, the hook should be as:
> >
> > Value *
> > ac_database_create([arguments ...])
> > {
> > /*
> >* The default
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
> I think we need a two pronged attack on this issue. Eventually I think
> someone who wants this feature in there will need to sponsor someone
> (and not even necessarily a coder) to do a sizable round of plain old
> wording cleanup on the c
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> As Rober Haas already suggested in another message, my patch in the last
> commit fest is too large. It tried to rework anything in a single patch.
> The "per-object-type" basis make sense for me.
Agreed.
> In my cosmetic preference, "ace_" i
Joshua Brindle wrote:
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group o
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> (1) Whether the framework should host the default PG model, not only
>> enhanced security features, or not?
>> This patch tried to host both of the default PG model and SELinux.
>> But, the default PG model
Robert Haas wrote:
One comment I have in general about this process is that I think it
would enormously reduce the level of pain associated with making these
kinds of changes if we could get patches that were not full of minor
issues that need to be cleaned up (like comments not properly
adjusted
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> (1) Whether the framework should host the default PG model, not only
> enhanced security features, or not?
> This patch tried to host both of the default PG model and SELinux.
> But, the default PG model does not have same origin with
Stephen Frost wrote:
> * Greg Smith (g...@2ndquadrant.com) wrote:
>> I personally feel that Steven
>> Frost's recent comments here about how the PostgreSQL code makes this
>> harder than it should be really cuts to the core of a next step here.
>> The problem facing us isn't "is SEPostgreSQL
On Thu, Dec 10, 2009 at 10:39 PM, Stephen Frost wrote:
> Let's start by taking the patch I reviewed and splitting up
> security/access_control.c along object lines. Of course, the individual
> security/_ac.c files would only include the .h's that are
> necessary. This would be a set of much smal
Stephen Frost wrote:
* Greg Smith (g...@2ndquadrant.com) wrote:
I have to be honest and say that I'm not optimistic that this is
possible or even a good idea to accomplish in the time remaining during
this release.
While I agree with you, I wish you hadn't brought it up. :) Mostly
* Greg Smith (g...@2ndquadrant.com) wrote:
> I personally feel that Steven
> Frost's recent comments here about how the PostgreSQL code makes this
> harder than it should be really cuts to the core of a next step here.
> The problem facing us isn't "is SEPostgreSQL the right solution for
>
Greg Smith wrote:
> It's funny; we started out this CommitFest with me scrambling to find
> someone, anyone, willing to review the latest SE-PostgreSQL patch,
> knowing it was a big job and few were likely to volunteer. Then
> schedules lined up just right, and last night I managed to get a gre
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group of people all to
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
My concern is "access_control_" is a bit long for prefixes,
but "ac_" is too short to represent what it is doing.
>>> pg_ac_? Still shorter than 'secur
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> >> My concern is "access_control_" is a bit long for prefixes,
> >> but "ac_" is too short to represent what it is doing.
>
> > pg_ac_? Still shorter than 'security_', uses the pg_ p
Stephen Frost writes:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> My concern is "access_control_" is a bit long for prefixes,
>> but "ac_" is too short to represent what it is doing.
> pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
> use in a number of other places,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> David Fetter wrote:
> > On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
> > Just generally, "access control" is a great way to describe what's
> > actually happening here. That people conflate access control with
> > security has result
David Fetter wrote:
> On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>>> I began to describe the list of abstraction layer functions (but not
>>> completed yet):
>>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstrac
On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> > I began to describe the list of abstraction layer functions (but not
> > completed yet):
> > http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> I began to describe the list of abstraction layer functions (but not
>> completed yet):
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really a huge fan of 'security_' as a prefix for th
On Mon, Aug 3, 2009 at 10:19 PM, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>> - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-No
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> I began to describe the list of abstraction layer functions (but not
> completed yet):
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
I'm not really a huge fan of 'security_' as a prefix for these
functions, but I don't have a
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>> - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-Nov)
>> - basic functionality of
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> So, we may be able to modify the development plan as follows:
> * 2nd CommitFest (15-Sep)
> - security abstraction layer
> (- largeobject permission)
>
> * 3rd CommitFest (15-Nov)
> - basic functionality of SE-PostgreSQL
>
> * 4th CommitFe
Robert Haas wrote:
> 2009/8/3 KaiGai Kohei :
>> I now plans to submit two patches for the next commit fest.
>> The one is implementation of the abstraction layer.
>> The other is basic implementation of the SE-PostgreSQL.
>
> Is this a good idea, or would it be better to focus on the aclcheck
> st
2009/8/3 KaiGai Kohei :
> I now plans to submit two patches for the next commit fest.
> The one is implementation of the abstraction layer.
> The other is basic implementation of the SE-PostgreSQL.
Is this a good idea, or would it be better to focus on the aclcheck
stuff (which is what I understan
gt; - Original Message
> From: KaiGai Kohei
> To: Stephen Frost
> Cc: KaiGai Kohei ; Robert Haas ;
> pgsql-hackers@postgresql.org; Greg Williamson ; Sam
> Mason ; Joshua Brindle
> Sent: Monday, August 3, 2009 12:09:45 AM
> Subject: Re: [HACKERS] SE-PostgreSQL Specif
mson ; Sam
Mason ; Joshua Brindle
Sent: Monday, August 3, 2009 12:09:45 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Stephen Frost wrote:
>> I think what I should do on the next is ...
>> - To check up whether it is really possible to implement SELinux's model.
>&
Stephen Frost wrote:
>> I think what I should do on the next is ...
>> - To check up whether it is really possible to implement SELinux's model.
>> - To describe the list of the security functions in the new abstraction
>> layer.
>> - To discuss the list of permission at:
>>
>> http://wiki.post
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> Please note that all we need to focus on is not pg_xxx_aclcheck() routines
> in other words.
I agree, there may be other things which need to move to aclchk.c, and
that routine is a good example of something which would be appropriate
to move,
Stephen Frost wrote:
>> For example:
>> void pg_security_alter_table(Oid relid)
>> {
>> if (!pg_class_ownercheck(relid, GetUserId())
>> aclcheck_error(...);
>>
>> if (!sepgsqlCheckTableSetattr(relid))
>> selinux_error(...);
>> }
>
> Right, something along thes
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> As I noted in the reply to Stephen Frost, "what should be controled"
> (e.g, ALTER TABLE) and "how to check it" (e.g, ownership based control)
> are different things.
>
> If we go on the direction to restructure the current aclcheck mechanism
> and to i
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> It seems to me your suggestion is similar to the idea of PGACE framework.
It is, but it's being done as incremental changes to the existing
structures, and working with them, instead of ignoring that they exist.
> Let's consider the matter mo
Robert Haas wrote:
FWIW, pretty much +1 from me on everything in here; I think this is
definitely going in the right direction. It's not the size of the
patches that matter; it's the complexity and difficulty of verifying
that they don't break anything. And it's not cumulative: three easy
patch
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> Stephen Frost wrote:
>>> Strategy for code changes:
>>> Patch #1: Move permissions checks currently implemented in other parts
>>> of the code (eg: tablecmds.c:ATExecChangeOwner()) into
>>>
On Fri, Jul 31, 2009 at 5:13 PM, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> Stephen Frost wrote:
>> > Strategy for code changes:
>> > Patch #1: Move permissions checks currently implemented in other parts
>> > of the code (eg: tablecmds.c:ATExecC
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> Stephen Frost wrote:
> > Strategy for code changes:
> > Patch #1: Move permissions checks currently implemented in other parts
> > of the code (eg: tablecmds.c:ATExecChangeOwner()) into
> > aclchk.c.
> > Patc
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> For the recent a few days, I've worked to write and edit
>> the specification (partially copied from the draft of user
>> documentation) for the development purpose.
>>
>> http://wiki.postgresql.org/wiki/SEPostgreS
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> For the recent a few days, I've worked to write and edit
> the specification (partially copied from the draft of user
> documentation) for the development purpose.
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
Thanks for doin
As Peter Eisentraut pointed out, we are not on the phase
to discuss about user documentations yet.
It is a reasonable idea to discuss correct specifications
of SE-PostgreSQL from the viewpoint of the developers.
Then, it will the a good source for the upcoming user docs.
For the recent a few days
Peter Eisentraut wrote:
> On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
>> Peter Eisentraut wrote:
>>> On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definition
ve a few paragraphs done so you can check it and see
> if you approve.
>
> Apologies for top-posting -- lame mailer.
>
> Greg W.
>
>
>
>
> - Original Message
> From: KaiGai Kohei
> To: KaiGai Kohei
> Cc: Sam Mason ; pgsql-hackers@postgresql
On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
> Peter Eisentraut wrote:
> > On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
> >> I'm coming to the conclusion that you really need to link to external
> >> material here; there must be good (and canonical) definitions of these
> >> things outs
ly) and I just had a pretty young skunk and two raccoon kits in
rapid order and I have to clean up and secure the premises.
Regards!
G
- Original Message
From: Greg Williamson
To: KaiGai Kohei ; KaiGai Kohei
Cc: Sam Mason ; pgsql-hackers@postgresql.org
Sent: Tuesday, July 2
Peter Eisentraut wrote:
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to l
hackers@postgresql.org
Sent: Tuesday, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
Thanks for the updates.
I might suggest a couple of small changes:
a) a section that explains comments like "This is not supported in the initial
version" -- do you
On Mon, Jul 27, 2009 at 01:53:07PM -0400, Chris Browne wrote:
> s...@samason.me.uk (Sam Mason) writes:
> > On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
> >> Robert Haas wrote:
> >> In some cases, the clearance of infoamtion may be changed. We often
> >> have dome more complex requi
- Original Message
From: KaiGai Kohei
To: KaiGai Kohei
Cc: Sam Mason ; pgsql-hackers@postgresql.org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
> I'm coming to the conclusion that you really need to link to external
> material here; there must be good (and canonical) definitions of these
> things outside and because SE-PG isn't self contained I really think you
> need to link to them.
This
I revised the SE-PostgreSQL Specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "m
Greg Williamson wrote:
> KaiGai --
>
> I have a few suggestions which I will post in a bit, and some
> rather extensive edits of the existing Wiki, mostly for syntax
> rather than content.
>
> How do you want the latter ? I can email them offline as text,
> or you could set me up with a login on
KaiGai --
I have a few suggestions which I will post in a bit, and some rather extensive
edits of the existing Wiki, mostly for syntax rather than content.
How do you want the latter ? I can email them offline as text, or you could set
me up with a login on the wiki and I could do them in plac
Chris Browne wrote:
> s...@samason.me.uk (Sam Mason) writes:
>> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>>> Robert Haas wrote:
>>> In some cases, the clearance of infoamtion may be changed. We often
>>> have dome more complex requirements also.
>> OK, so there is some other tr
s...@samason.me.uk (Sam Mason) writes:
> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>> Robert Haas wrote:
>> In some cases, the clearance of infoamtion may be changed. We often
>> have dome more complex requirements also.
>
> OK, so there is some other trusted entity that has unf
Andrew Dunstan wrote:
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called
"unconfined".
However, it is also *possible* to define a new special proc
Robert Haas wrote:
> If you want to store intelligence data about the war in Iraq and
> intelligence data about the war in Afghanistan, it might not be too
> bad to store them in separate databases, though storing them in the
> same database might also make things simpler for users who have access
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called
"unconfined".
However, it is also *possible* to define a new special process
privilege
for back
Andrew Dunstan wrote:
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called "unconfined".
However, it is also *possible* to define a new special process privilege
for backup and restore tools. For
Sam Mason wrote:
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
Indeed, the draft used the term of "security context" with minimum
introductions, but not enough friendliness for database folks.
The purpose of security context is an identifier of any subject and
object to describe
KaiGai Kohei wrote:
The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called "unconfined".
However, it is also *possible* to define a new special process privilege
for backup and restore tools. For example, it can access
On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
> Indeed, the draft used the term of "security context" with minimum
> introductions, but not enough friendliness for database folks.
>
> The purpose of security context is an identifier of any subject and
> object to describe them in t
On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
> Robert Haas wrote:
> >Sam Mason wrote:
> >>The traditional approach would be to maintain multiple physically
> >>separate databases; in this setup it's obvious that when you perform a
> >>backup of one of these databases you're only se
Robert Haas wrote:
If superusers DON'T exist, that would be making the opposite
statement, namely, that there isn't ANY WAY to get a backup that you
can be sure DOES contain all of the objects.
The traditional approach would be to maintain multiple physically
separate databases; in this setup it
Sam Mason wrote:
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason wrote:
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the power they currently do.
It's been billed that way, but it's not real
On Sat, Jul 25, 2009 at 7:49 PM, Sam Mason wrote:
> On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
>> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason wrote:
>> > I thought the whole point of MAC was that superusers don't exist any
>> > more--at least not with the power they currently do.
>
Robert Haas wrote:
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei wrote:
| Access control is conceptually to decide a set of allowed (or denied)
| actions between a certain subject (such as a database client) and an
| object (such as a table), and to apply the decision on user's requests.
| At t
On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei wrote:
> | Access control is conceptually to decide a set of allowed (or denied)
> | actions between a certain subject (such as a database client) and an
> | object (such as a table), and to apply the decision on user's requests.
> | At the database pr
Sam Mason wrote:
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
Sorry for using the undefined terminology.
I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is understan
On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason wrote:
> > I thought the whole point of MAC was that superusers don't exist any
> > more--at least not with the power they currently do.
>
> It's been billed that way, but it's not really accu
On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason wrote:
> On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
>> There had better still be superusers. Or do you want the correctness
>> of your backups to depend on whether your SELinux policy is correct?
>
> I thought the whole point of MAC was tha
On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
> There had better still be superusers. Or do you want the correctness
> of your backups to depend on whether your SELinux policy is correct?
I thought the whole point of MAC was that superusers don't exist any
more--at least not with the
On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
> Sorry for using the undefined terminology.
I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is understandable/usable by any
On Jul 25, 2009, at 11:06 AM, Tom Lane wrote:
Sam Mason writes:
Yes, that seems reasonable. The fact that you're still talking about
"confined users" is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
terminology thing though
Sam Mason writes:
> Yes, that seems reasonable. The fact that you're still talking about
> "confined users" is slightly worrying and would seem to imply that
> there is still a superuser/normal user divide--it's probably just a
> terminology thing though.
There had better still be superusers. O
Sam Mason wrote:
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:
CREATE OR REPLACE FUNCTION s
On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
> Sam Mason wrote:
> >This would seem to imply that all user defined trusted code has to
> >perform its own permission checks. How is MAC any different from DAC in
> >the presence of code such as:
> >
> >CREATE OR REPLACE FUNCTION show_
Sam Mason wrote:
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
Sam Mason wrote:
The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a
On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
> Sam Mason wrote:
> >The show_credit() function in this section would seem to leak authority
> >as well; it seems possible to determine if customers exist that
> >otherwise may otherwise hidden. For example, imagine we have a row
> >in
Sam Mason wrote:
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
Thanks, but I found an incorrect change at the trusted procedure section.
Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
- SECURITY_LABE
On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
> Thanks, but I found an incorrect change at the trusted procedure section.
>
> Old)
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32)
> - SECURITY_LABEL =
On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frost wrote:
> Thanks for this, it really does help, I believe. I've been reviewing it
> and am also planning on helping refine and improve upon it. I'd like to
> spend time working on the patch as well but I'm hesitant to commit to
> that right now due to
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Here is the initial draft of SE-PostgreSQL specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve u
Martijn van Oosterhout wrote:
> On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
>> Here is the initial draft of SE-PostgreSQL specifications:
>>
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
>
> Hey, this is really cool. Think it is a nice introduction. Fixed some
> of t
On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
> Here is the initial draft of SE-PostgreSQL specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really obvious language stuff and an
Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got
some non-work related issues which may keep from giving this a good look until
the weekend (FWIW). I'll post any questions I have.
Thanks,
Greg W.
- Original Message
From: KaiGai Kohei
To: Robert Haas
Cc:
Robert Haas wrote:
> I think the best thing for this patch right now is to move it to
> "Returned with Feedback". I can't see any way that this patch is
> going to be made committable for this CommitFest, and I think that
> pretending otherwise is only encouraging KaiGai to do another of his
> lig
Here is the initial draft of SE-PostgreSQL specifications:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
I've described it from the scratch again with paying attention
for the people knowing nothing about SELinux.
In some points, it uses comparison between the database privilege
mechanism
On Sat, Jul 18, 2009 at 12:06 PM, David Fetter wrote:
> At this point, SE-PostgreSQL has taken up a *lot* of community
> resources, not to mention an enormous and doubtless frustrating amount
> of Kohei-san's time and effort, thus far without a single committed
> patch, or even a consensus as to wh
1 - 100 of 169 matches
Mail list logo
