Peter Eisentraut wrote:
> On Monday 20 July 2009 17:52:44 Joshua Brindle wrote:
>> That is your (and the communities) prerogative. Linus wasn't very
>> supportive of SELinux in the kernel either but it is the only way Linux got
>> an EAL4+ LSPP evaluation for use in certain government systems. I
>>
On Monday 20 July 2009 17:52:44 Joshua Brindle wrote:
> That is your (and the communities) prerogative. Linus wasn't very
> supportive of SELinux in the kernel either but it is the only way Linux got
> an EAL4+ LSPP evaluation for use in certain government systems. I
> personally would love to see
Greg Stark wrote:
> On Tue, Jul 21, 2009 at 5:51 AM, Robert Haas wrote:
>> I really, really think you need to find someone to help you with the
>> documentation. As I've said before, your English is a lot better than
>> my Japanese, but the current documentation is just hard to read.
>
>
> In ge
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
You also snipped the other scenario I had where row based access control
isn't required but column level and stored procedure level are.
Well we already have column level and stored procedure privileges.
Greg Stark wrote:
> On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
>> You also snipped the other scenario I had where row based access control
>> isn't required but column level and stored procedure level are.
>
> Well we already have column level and stored procedure privileges.
>
>> I u
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
> You also snipped the other scenario I had where row based access control
> isn't required but column level and stored procedure level are.
Well we already have column level and stored procedure privileges.
> I understand
> you already have
Greg Stark wrote:
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle wrote:
Backing up from KaiGai's description a bit, basically what this is needed
for is storing multilevel data in a single db instance.
For example, you have people logging in from different classifications
(unclass, secret, to
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle wrote:
>
> Backing up from KaiGai's description a bit, basically what this is needed
> for is storing multilevel data in a single db instance.
>
> For example, you have people logging in from different classifications
> (unclass, secret, top secret, e
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
I am capable of speaking for Tresys in this matter. We are very interested
in this work and our US DoD customers need the capabilities that this
project adds (assuming row level access controls are a possibility).
I'm k
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haas wrote:
>
> I really, really think you need to find someone to help you with the
> documentation. As I've said before, your English is a lot better than
> my Japanese, but the current documentation is just hard to read.
In general we're very generous w
Greg Williamson wrote:
> KaiGai Kohei asked:
>
>
> <...>
>
>> Here is one idea. I'll upload the draft of the documentation on the
>> wikipage shorter than the current one.
>> Is somebody available to check it from the viewpoint of native English
>> user or database users?
>
> I'll give a shot .
KaiGai Kohei asked:
<...>
>
> Here is one idea. I'll upload the draft of the documentation on the
> wikipage shorter than the current one.
> Is somebody available to check it from the viewpoint of native English
> user or database users?
I'll give a shot ... native english speaker, some exper
Robert Haas wrote:
> 2009/7/20 KaiGai Kohei :
>> Robert Haas wrote:
>>> - row-level security
>>> - complex DDL permissions
>> Is the complex DDL permissions mean something like db_xxx:{create},
>> db_xxx:{relabelfrom relabelto} and others?
>> If so, I can agree to implement these checks at the late
2009/7/20 KaiGai Kohei :
> Robert Haas wrote:
>> - row-level security
>> - complex DDL permissions
>
> Is the complex DDL permissions mean something like db_xxx:{create},
> db_xxx:{relabelfrom relabelto} and others?
> If so, I can agree to implement these checks at the later patch.
>
> However, ple
Robert Haas wrote:
> I have attempted, on the relevant threads, to enumerate those problems
> as I see them. Mainly they have to do with hooks all over the code in
> strange and unmaintainable places, documentation that is written in
> poor English and is not easily understandable by people who ar
How many people are you looking for? Is there a number or are you
waiting for a good feeling?
The problem is not the number of people who like the patch, but the
number of people who are willing to refactor and maintain it. Right
now, if NEC decided to abandon Postgres, or if they decided
Greg Stark wrote:
> On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
>> I am capable of speaking for Tresys in this matter. We are very interested
>> in this work and our US DoD customers need the capabilities that this
>> project adds (assuming row level access controls are a possibility).
>
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
> I am capable of speaking for Tresys in this matter. We are very interested
> in this work and our US DoD customers need the capabilities that this
> project adds (assuming row level access controls are a possibility).
I'm kind of curious ab
On Mon, Jul 20, 2009 at 3:44 PM, Joshua Brindle wrote:
> Ron Mayer wrote:
>>
>> Joshua Brindle wrote:
>>>
>>> How many people are you looking for? Is there a number or are you
>>> waiting for a good feeling?
>>
>>
>
>> Joshua - if you're still associated with Tresys - could someone
>> who could sp
Joshua Brindle wrote:
Peter Eisentraut wrote:
When it comes to larger features, this development group has a great
deal of
experience in implementing existing specifications, even relatively
terrible
ones like SQL or ODBC or Oracle compatibility. But the expected
behavior has
to be writte
Peter Eisentraut wrote:
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you waiting
for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
Wha
Ron Mayer wrote:
Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you
waiting for a good feeling?
Joshua - if you're still associated with Tresys - could someone
who could speak for that company say what they think about this
project? The seem quite in-t
Joshua Brindle wrote:
> How many people are you looking for? Is there a number or are you
> waiting for a good feeling?
Is it individuals or organizations people are looking for?
I see KaiGai wrote "In addition, I (and NEC) can provide our
capability to the PostgreSQL community to keep these secu
Peter Eisentraut wrote:
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you waiting
for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
What
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
> How many people are you looking for? Is there a number or are you waiting
> for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
What is lacking here is a wr
Joshua Brindle escribió:
> The unfortunate part is that many of the people that would use it are
> unable to publicly say so.
So they will be similarly unable to help with it. Such a black hole is
not of much use, is it? Or are they getting a contract with some PG
support company to which they
Tom Lane wrote:
Martijn van Oosterhout writes:
I'm asking because from my position it looks like KaiGai is being
simultaneously told "you patch is too big, make it smaller" and "your
patch is not complete (with respect to some metric), make it bigger"
and we need to define a middle ground if we
Martijn van Oosterhout writes:
> I'm asking because from my position it looks like KaiGai is being
> simultaneously told "you patch is too big, make it smaller" and "your
> patch is not complete (with respect to some metric), make it bigger"
> and we need to define a middle ground if we want to av
Martijn van Oosterhout wrote:
On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
Specifically, creating SELinux permissions for CREATE LANGUAGE seems
particularly useless since that's not a data protection issue. The same
with aggregates, operator classes, etc. ISTM the goal of SELi
On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
>>> Specifically, creating SELinux permissions for CREATE LANGUAGE seems
>>> particularly useless since that's not a data protection issue. The same
>>> with aggregates, operator classes, etc. ISTM the goal of SELinux is not
>>> primar
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout wrote:
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being ac
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout wrote:
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being acc
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout wrote:
> On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
>> > I'm starting to think that there's just no hope of this matching up
>> > well enough with the way PostgreSQL already works to have a chance of
>> > being accepted.
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
> > I'm starting to think that there's just no hope of this matching up
> > well enough with the way PostgreSQL already works to have a chance of
> > being accepted.
>
> What I'm understanding here is the apparent requirement that t
On Friday 17 July 2009 06:10:12 Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
> > Yes, the tiny version will not give any advantages in security without
> > future enhancements.
> > It is not difficult to add object classes and permissions.
> > If necessary, I'll add checks them with corresponding
Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
>> Yes, the tiny version will not give any advantages in security without
>> future enhancements.
>> It is not difficult to add object classes and permissions.
>> If necessary, I'll add checks them with corresponding permissions.
>>
>> One anxiety is Po
2009/7/16 KaiGai Kohei :
> Yes, the tiny version will not give any advantages in security without
> future enhancements.
> It is not difficult to add object classes and permissions.
> If necessary, I'll add checks them with corresponding permissions.
>
> One anxiety is PostgreSQL specific object cl
Robert Haas wrote:
> 2009/7/16 KaiGai Kohei :
>> Updated SE-PgSQL patch is here:
>>
>> http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
>>
>> Unused definitions of SELinux's permissions are ripped out from
>> the permission table.
>
> OK, I'm looking at this version of
2009/7/16 KaiGai Kohei :
> Updated SE-PgSQL patch is here:
>
> http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
>
> Unused definitions of SELinux's permissions are ripped out from
> the permission table.
OK, I'm looking at this version of the patch, and my first reactio
Updated SE-PgSQL patch is here:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2196.patch.gz
Unused definitions of SELinux's permissions are ripped out from
the permission table.
KaiGai Kohei wrote:
> The following patch is the tiny version of SE-PostgreSQL:
>
> http://sepgsq
40 matches
Mail list logo
