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 an
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
Robert Haas wrote:
2009/7/20 KaiGai Kohei kai...@ak.jp.nec.com:
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
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 experience
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 ... native
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com 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
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindlemet...@manicmethod.com 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
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindlemet...@manicmethod.com 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,
Greg Stark wrote:
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindlemet...@manicmethod.com 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
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindlemet...@manicmethod.com 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
Greg Stark wrote:
On Tue, Jul 21, 2009 at 5:51 AM, Robert Haasrobertmh...@gmail.com 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
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhoutklep...@svana.org 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
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
primarily to
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
Martijn van Oosterhout klep...@svana.org 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
Tom Lane wrote:
Martijn van Oosterhoutklep...@svana.org 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
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
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
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
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
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?
snip
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
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.
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
On Mon, Jul 20, 2009 at 3:44 PM, Joshua Brindlemet...@manicmethod.com 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?
snip
Joshua - if you're still associated with Tresys - could someone
who
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindlemet...@manicmethod.com 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).
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindlemet...@manicmethod.com 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
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
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 are
2009/7/20 KaiGai Kohei kai...@ak.jp.nec.com:
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.
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhoutklep...@svana.org 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
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 the
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhoutklep...@svana.org 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
On Friday 17 July 2009 06:10:12 Robert Haas wrote:
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
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
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
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
Robert Haas wrote:
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
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
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
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
Robert Haas wrote:
2009/7/16 KaiGai Kohei kai...@ak.jp.nec.com:
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
The following patch is the tiny version of SE-PostgreSQL:
http://sepgsql.googlecode.com/files/sepgsql-01-tiny-8.5devel-r2193.patch.gz
In this version, all the security hooks (to make decision) invoked from
outside of the pg_xxx_aclcheck() and superuser_arg() were separated.
So, SE-PgSQL/tiny
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:
41 matches
Mail list logo
