Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch r2363 ]
I promised I would review this today, but I just can't make myself do it
in any detail. This is too large, too ugly, and it is going in a
direction that I do not like or want to spend any of my time
that this reworking does not go into
the right direction? Or, my comment on the last message?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Tom Lane wrote:
The most serious problem is that you ripped out myLargeObjectExists(),
apparently because you didn't understand what it's there for. The reason
Robert Haas wrote:
2009/10/13 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a revised one with the following updates:
Despite two fairly explicit requests, this patch (and, with the
exception of ECPG, only this patch) has not yet been reviewed by a
committer.
http
Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
2009/10/14 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Tom Lane wrote:
The most serious problem is that you ripped out myLargeObjectExists
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
The attached patch is the revised one for largeobejct access controls,
because it conflicted to the GRANT/REVOKE ON ALL xxx IN SCHEMA.
I started to look through this patch with the hope of committing it, but
found out that it's
insertions(+), 80 deletions(-), 193 modifications(!)
KaiGai Kohei wrote:
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
Quick comment on this --- I think
Stephen, Thanks for your reviewing comments, although you have busy days.
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Please review the new revision, Thanks,
In general, I'm pretty happy with this revision. You still have a
number of places where you have
or philosophy.
Is it confusable? Is there any more appropriate terms?
KaiGai Kohei wrote:
Peter Eisentraut wrote:
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
CREATE TABLE tbl_p (int a, int b);
CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
SELECT a,b FROM tbl_p; -- It selects data from only
Petr Jelinek wrote:
KaiGai Kohei napsal(a):
I tried to check the default ACL behavior.
It works for me fine, good, but ...
postgres= SELECT * INTO t3 FROM t1;
SELECT
postgres= SELECT * FROM t3;
a | b
---+-
1 | aaa
2 | bbb
(2 rows)
postgres= INSERT INTO t3
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Was it uncertain what I wanted to say for the proposition?
No: it's that nobody sees any particular value in making a fundamental
restructuring of the permissions system like that. What you propose
would be far harder/more
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
Quick comment on this --- I think that using a syscache for large
objects is probably not a good idea
Alvaro Herrera wrote:
KaiGai Kohei escribió:
I added a syscache entry for pg_largeobject_metadata, not pg_largeobject
which contains data chunks. The pg_largeobject_metadata is a smaller catalog
than most of system catalogs, such as pg_class.
The point is not the size of the cache entries
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
I rebased the largeobject access controls patch to the CVS HEAD
because of the patch confliction to the default ACL patch.
Quick comment on this --- I think that using a syscache for large
objects is probably not a good idea
Tom Lane wrote:
Petr Jelinek pjmo...@pjmodos.net writes:
KaiGai Kohei napsal(a):
SELECT INTO does not check ACL_INSERT on the newly created tables, because
we had been able to assume the table owner always has privilege to insert
values into the new table.
So, OpenIntoRel() didn't check
Peter Eisentraut wrote:
On Mon, 2009-10-05 at 12:15 +0900, KaiGai Kohei wrote:
On the other hand, it also needs to check permission both of child
table and its parents when we select data from a table with its
parents,
You can't do that anyway.
Sorry, I'm not clear why it is impossible
Peter Eisentraut wrote:
On Mon, 2009-10-05 at 16:27 +0900, KaiGai Kohei wrote:
CREATE TABLE tbl_p (int a, int b);
CREATE TABLE tbl_c (int x) INHERITS(tbl_p);
SELECT a,b FROM tbl_p; -- It selects data from only tbl_p.
It is reasonable to bypass checks on tbl_c
Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-02-blob-8.5devel-r2353.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
added due to the default ACL feature?
IMO, we don't need to hurry-up to catch up these new features just
now, because we have only a week in this commit fest.
It is desirable to improve the patch being commitable earlier.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai
ACLs. I can't convince
myself whether that's a good idea though, so I left it as-is for the
moment.
regards, tom lane
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
the inherited columns are a part of the parent table,
individual checks can be bypassed. Otherwise, we can keep the compatible
bahavior.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
2009/10/1 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
On Thu, Oct 1, 2009 at 8:52 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
David E. Wheeler escreveu:
On Oct 1, 2009, at 3:42 PM, Tom Lane wrote:
My inclination is to think that the right behavior
Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen Frost wrote:
The scenario you outline could happen without SE-PG, couldn't it?
Specifically, if a user makes a connection, creates a temporary table,
and then their rights to create temporary tables are revoked? What
with this, it just might be a change
from what was done before when there were multiple permission checks
done.
Ahh, it was a communication bug. we talked same thing.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql
Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The attached patch eliminates permission checks in FindConversion()
and EnableDisableRule(), because these are nonsense or redundant.
It is an separated issue from the ac_*() routines.
For now, we decided
Stephen, thanks for your comments.
Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Could you post any review comments, even if it is not comprehensive yet?
In general, you don't need to preface your comments with 'MEMO:'. I
would encourage removing that. You might use
Stephen Frost wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
You might also provide a specific example of where and why this check
matters. I'm not entirely convinced it's necessary or makes sense, to
be honest..
By the default, it is 100% correct to omit checks
messages:
http://archives.postgresql.org/message-id/26499.1250706...@sss.pgh.pa.us
http://archives.postgresql.org/message-id/4abc136a.90...@ak.jp.nec.com
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
Index: base/src/backend/rewrite/rewriteDefine.c
Thanks for your comments.
Jaime Casanova wrote:
2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is revised from the previous revision at the following
points:
- The largeobject_compat_acl is renamed to largeobject_check_acl.
Its default is on, and turning it off means
Stephen Frost wrote:
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
BTW, I raised a few issues. Do you have any opinions?
Certainly, though they're my opinions and I don't know if the committers
will agree, but I suspect they will.
Thanks for your comments.
* deployment of the source code
Jaime Casanova wrote:
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
Jaime,
KaiGai Kohei wrote:
| ALTER LARGE OBJECT is working, but now that we can change the owner of
| a LO we should be able to see who the actual owner is... i mean we
| should add an owner column in \dl for psql (maybe
Jaime Casanova wrote:
2009/9/24 KaiGai Kohei kai...@ak.jp.nec.com:
Example)
postgres=# SET SESSION AUTHORIZATION ymj;
SET
postgres= SELECT loread(lo_open(16453, x'4'::int), 20);
ERROR: permission denied for largeobject 16453
postgres=# SET largeobject_compat_acl
|1
src/test/regress/expected/privileges.out | 206 +++
src/test/regress/expected/sanity_check.out|3
src/test/regress/sql/privileges.sql | 85 ++
32 files changed, 976 insertions(+), 77 deletions(-), 316 modifications(!)
KaiGai Kohei wrote
, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jaime,
KaiGai Kohei wrote:
| ALTER LARGE OBJECT is working, but now that we can change the owner of
| a LO we should be able to see who the actual owner is... i mean we
| should add an owner column in \dl for psql (maybe \dl+) and maybe an
| lo_owner() function.
|
| I would like to buy your
Robert Haas wrote:
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
Now, I'm revising the patch as follows:
- pg_largeobject_meta is renamed to pg_largeobject_metadata
- The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
- psql supports \dl to show owner of the largeobject
(!)
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-02-blob-8.5devel-r2327.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Jaime, Thanks for your reviewing.
Jaime Casanova wrote:
2009/9/6 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is an update of largeobject access controls.
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now
by the abstraction of ac_rule_toggle()
in my patch. However, it may be better to remove the checks simply.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
largeobject
SET
postgres=# SET SESSION AUTHORIZATION ymj;
SET
postgres= SELECT loread(lo_open(1234, x'4'::int), 100);
loread
\x
(1 row)
KaiGai Kohei wrote:
Robert Haas wrote:
2009/9/3 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
KaiGai
is
not delivered to executor...
What is the correct behavior when UPDATE statement set a new
value but it was identical to the original value?
In this case, heap_tuple_attr_equals() cannot detect the column
is used as a target of the UPDATE.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
BTW, currently, the default ACL of largeobject allows anything for owner
and nothing for world. Do you have any comment for the default behavior?
Mph. I think the backlash will be too great
Robert Haas wrote:
2009/9/3 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
BTW, currently, the default ACL of largeobject allows anything for owner
and nothing for world. Do you have any comment
Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
deletions(-), 237 modifications(!)
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-02-blob-8.5devel-r2272.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Alvaro Herrera wrote:
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
BTW, currently, the default ACL of largeobject allows anything for owner
and nothing for world. Do you have any comment for the default behavior?
Mph. I think the backlash will be too great. You have to leave
Itagaki Takahiro wrote:
KaiGai Kohei kai...@ak.jp.nec.com wrote:
The pg_largeobject system catalog is reworked to manage its metadata.
CATALOG(pg_largeobject,2613)
{
Oid loowner;/* OID of the owner */
Oid lochunk;/* OID of the data chunks
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
The attached patch provides access control features on largeobject.
This patch adds the ownership and two permissions (SELECT and UPDATE) on
largeobjects. The two permissions controls reader and writer accesses to
the largeobejcts
,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
/largeobject.source | 10
src/test/regress/sql/privileges.sql| 75 ++
29 files changed, 857 insertions(+), 107 deletions(-), 388 modifications(!)
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
sepgsql-02-blob-8.5devel-r2264.patch.gz
Description: application
comment?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
KaiGai Kohei wrote:
The following url is a patch to rework access control facilities in
PostgreSQL.
http://sepgsql.googlecode.com/files/sepgsql-01-base-8.5devel-r2251.patch.gz
IIRC, the limitation of attachment was 40kb, so I resent it using a pointing URL
instead of attachment, sorry
.
But it is checked when we lookup the target conversion on DDL statement.
It's unclear for me what is the intension of this check.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
When FindConversion() is called, it also checks current user's ACL_EXECUTE
privilege on the conproc of the fetched conversion.
Why this check is applied on FindConversion(), instead of
FindDefaultConversion()?
Does seem pretty
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
-PostgreSQL.
For example:
http://code.google.com/p/sepgsql/source/browse/tags/sepgsql/src/test/sepgsql
Thanks,
And let me add, I am in awe of your efforts on this !
G
- Original Message
From: KaiGai Kohei kai...@ak.jp.nec.com
To: Stephen Frost sfr...@snowman.net
Cc: KaiGai
Robert Haas wrote:
2009/8/3 KaiGai Kohei kai...@ak.jp.nec.com:
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
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 SE-PostgreSQL
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
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_Abstraction
I'm
plans to support access controls on the
following database objects and permissions at the first stage.
* databases
* schemas
* tables
* columns
* sequences
* functions
* tablespaces
Do you have any comment for the directions?
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai
to say.
Please feel free to ask / point out me, if something unclear or
not-easy understandable.
Thanks,
KaiGai Kohei wrote:
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
the contents of largeobject on TOAST relation.
(including hole support)
- It provides largeobejct interfaces to write it partially.
Thanks,
KaiGai Kohei wrote:
I summarized the design proposal and issues currently we have.
I would like to see any comments corresponding to the proposition.
Especially
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
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
aclchk.c
control)
are different things.
If we go on the direction to restructure the current aclcheck mechanism
and to integrate entry points of security features into a single file,
I really really want an implementation independent layer which focuses
on access controls.
Thanks,
--
KaiGai Kohei kai
of permission at:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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) definitions
and mandatory access
controls.
- Revised whole of the composition in the Brief overview section.
- Put an example of security policy rule.
- SECURITY_LABEL option was replaced by SECURITY_CONTEXT to
avoid meaningless confusion.
I believe it become better than previous revision.
Thanks,
KaiGai Kohei
different viewpoint,
I'll provide it.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in
rapid order and I have to clean up and secure the premises.
Regards!
G
- Original Message
From: Greg Williamson gwilliamso...@yahoo.com
To: KaiGai Kohei kai...@ak.jp.nec.com; KaiGai Kohei kai...@kaigai.gr.jp
Cc: Sam Mason s...@samason.me.uk; pgsql-hackers@postgresql.org
Sent: Tuesday
of wikipages at:
http://wiki.postgresql.org/wiki/SEPostgreSQL
Thanks,
I'll send mail when I have 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 kai...@ak.jp.nec.com
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 trusted entity
the structure of chapters/sections in former of
the documentation to reduce usage of undefined terminology and
so on. Sorry, if it overlapped with your efforts.
And, please note that the 3.2 Access controls section is still
on work.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
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
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
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
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
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
,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for backup options to
pg_dump command, but it will be necessary to be reviewed.
It should contains what security context should be assigned on
the user shell which launches the pg_dump also.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql
in a single database instance here.
(If we don't want to use commercial solutions instead.)
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
I would like to improve documentation quality and fix its specification
during the discussion.
I am going to go ahead and mark this as Returned with Feedback.
Agreed.
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
more, but it's a really good start.
Have a nice day,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
is not enough English quality.
- And so on...
In addition, I would like to fix its specifications during the discussion.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
functionality to
satisfy these security functional components.
If certification is only valid on the patched version, rest of people
will not be happy.
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
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
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
to be allowed, or not.
On the other hand, table/column/row level access control is an issue
what objects to be controled.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
is a causality, but not all.
The matter is we've not been able to share what does it try to
achieve correctly, what is identicals or differences between
database privileges and SELinux's security model, and so on.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent
already provide a reference including a list of object classes and
permissions.
http://wiki.postgresql.org/wiki/SEPostgreSQL_References
I guess you would like to see when/where/how SE-PgSQL checks what permissions,
what criteria to make its decision should be used, and so on.
--
KaiGai Kohei
customers feel it fair for their purpose.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei kai...@ak.jp.nec.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to be implemented, and it will figure out
what implementation is better.
As I noted before, I've been flexible about how SE-PgSQL is implemented
as far as it can perform SELinux's security model correctly.
Please for a several days. I'll describe it.
--
OSS Platform Development Division, NEC
KaiGai
work correctly.
Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
401 - 500 of 907 matches
Mail list logo
