Tom Lane escribió:
> Alvaro Herrera writes:
> > KaiGai Kohei escribi�:
> >> One melancholic thing is adding a member into pg_proc.
> >> It defines more than 2000 of entries which I have to modify correctly. :(
> >> Is there any script to help it?
>
> > Try a search for "coccinelle", "sdiff", or w
Alvaro Herrera writes:
> KaiGai Kohei escribió:
>> One melancholic thing is adding a member into pg_proc.
>> It defines more than 2000 of entries which I have to modify correctly. :(
>> Is there any script to help it?
> Try a search for "coccinelle", "sdiff", or was it "spatch"? It got
> feature
KaiGai Kohei escribió:
> One melancholic thing is adding a member into pg_proc.
> It defines more than 2000 of entries which I have to modify correctly. :(
> Is there any script to help it?
Try a search for "coccinelle", "sdiff", or was it "spatch"? It got
featured on http://LWN.net/ not many we
If we add a field on pg_ to store security label in text form,
it is necessary to attach a default one at the following points.
* pg_class
- InsertPgClassTuple() at heap.c
* pg_attribute
- InsertPgAttributeTuple() at heap.c
* pg_proc
- ProcedureCreate() at pg_proc.c
* pg_database
-
Bruce Momjian wrote:
Joshua Brindle wrote:
The big problem is that the security value on system tables controls the
_object_ represented by the row, while on user tables the security value
represents access to the row. That is just an odd design, and why a
regular system table security value ma
Joshua Brindle wrote:
> > The big problem is that the security value on system tables controls the
> > _object_ represented by the row, while on user tables the security value
> > represents access to the row. That is just an odd design, and why a
> > regular system table security value makes sens
Bruce Momjian wrote:
KaiGai Kohei wrote:
Why an OID? We store acl items now without a lookup table; I think
there will be at most the same number of SE-Linux entries. Also, by
using text we avoid the problem of cleaning out unreferenced pg_security
rows, improve performance (no lookups), and
Bruce Momjian wrote:
At least, we cannot apply this scheme on the next phase (row-level)
due to the storage consumption and others. So, I don't think it is
a preferable way to design the first step without ignoring upcoming
expandability.
The big problem is that the security value on system tab
>> Why an OID? We store acl items now without a lookup table; I think
>> there will be at most the same number of SE-Linux entries. Also, by
>> using text we avoid the problem of cleaning out unreferenced pg_security
>> rows, improve performance (no lookups), and simplify the code.
>
> In additi
KaiGai Kohei wrote:
> > Why an OID? We store acl items now without a lookup table; I think
> > there will be at most the same number of SE-Linux entries. Also, by
> > using text we avoid the problem of cleaning out unreferenced pg_security
> > rows, improve performance (no lookups), and simplify
Bruce Momjian wrote:
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_cla
Robert Haas wrote:
> >> IANAC, but that's my impression too. The simplified patch shouldn't
> >> assume that row-level security in its current form is going to end up
> >> getting put back in. AFAICS, there's no reason why the security ID
> >> for tables can't be a regular attribute in pg_class,
On 1/30/09 5:43 PM, "Josh Berkus" wrote:
> Joshua, Kohei-san,
>
> So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
> features *except* row-level security, would it still be useful to the
> SELinux community?
>
Yes, it's definitely still useful. While many of the use cases
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
around row-level securi
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> Don't say patch too large. :D
Those are include files that are changing.. People do understand that
adding a column to a catalog can introduce alot of changed lines.
Stephen
signature.asc
Description: Digital signature
KaiGai Kohei wrote:
Andrew Dunstan wrote:
KaiGai Kohei wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify
correctly. :(
Is there any script to help it?
Last time I added a column to a large catalog, I used a perl sc
Andrew Dunstan wrote:
KaiGai Kohei wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Last time I added a column to a large catalog, I used a perl script to
help me, IIRC,
KaiGai Kohei wrote:
One melancholic thing is adding a member into pg_proc.
It defines more than 2000 of entries which I have to modify correctly. :(
Is there any script to help it?
Last time I added a column to a large catalog, I used a perl script to
help me, IIRC, but I haven't kept it.
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> One melancholic thing is adding a member into pg_proc.
> It defines more than 2000 of entries which I have to modify correctly. :(
> Is there any script to help it?
Not that I'm aware of.. You might be able to create an appropriate
regex though, esp.
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_class, or why the
securit
>> IANAC, but that's my impression too. The simplified patch shouldn't
>> assume that row-level security in its current form is going to end up
>> getting put back in. AFAICS, there's no reason why the security ID
>> for tables can't be a regular attribute in pg_class, or why the
>> security attr
Robert Haas wrote:
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost wrote:
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Stephen Frost wrote:
I think Bruce's question was where you stored the security_acl and
security_label columns. Based on your response (and a bit of purusal
through the code.g
>>> I think what people
>>> are looking for, instead, is either additional columns to just the
>>> existing system tables that need them (eg: pg_class, pg_attribute) or
>>> included in the existing ACL structure (the aclitem structure). Another
>>> option might be a seperate set of tables.
>> It s
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost wrote:
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> Stephen Frost wrote:
>> > I think Bruce's question was where you stored the security_acl and
>> > security_label columns. Based on your response (and a bit of purusal
>> > through the code.googl
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> Stephen Frost wrote:
> > I think Bruce's question was where you stored the security_acl and
> > security_label columns. Based on your response (and a bit of purusal
> > through the code.google site), it looks like you still have security_acl
>
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> I don't provide both of "security_label" and "security_acl"
>> system columns for system/user tables.
>> I didn't write it explicitly, it might make you confusing.
>>
>> User cannot see what security label is assigne
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> I don't provide both of "security_label" and "security_acl"
> system columns for system/user tables.
> I didn't write it explicitly, it might make you confusing.
>
> User cannot see what security label is assigned to them
> due to lack of syste
Bruce Momjian wrote:
KaiGai Kohei wrote:
Today, I'll debug the modified code...
Wow, that was fast. Where are you storing the security information for
tables and columns? Did you add a special column to pg_class, etc?
Security information is stored within padding field of HeapTupleHeader
as
KaiGai Kohei wrote:
> >> Today, I'll debug the modified code...
> >
> > Wow, that was fast. Where are you storing the security information for
> > tables and columns? Did you add a special column to pg_class, etc?
>
> Security information is stored within padding field of HeapTupleHeader
> as w
Bruce Momjian wrote:
KaiGai Kohei wrote:
Hasn't a plan for this already been posted? See
http://archives.postgresql.org/pgsql-hackers/2009-01/msg02407.php
FYI:
* previous full-functional SE-PostgreSQL/Row-ACLs
[kai...@fedora10 security]$ wc -l *.c */*.c
729 pgaceCommon.c
1547 pgaceHook
KaiGai Kohei wrote:
> > Hasn't a plan for this already been posted? See
> > http://archives.postgresql.org/pgsql-hackers/2009-01/msg02407.php
>
> FYI:
>
> * previous full-functional SE-PostgreSQL/Row-ACLs
>
> [kai...@fedora10 security]$ wc -l *.c */*.c
> 729 pgaceCommon.c
>1547 pgaceHoo
Andrew Dunstan wrote:
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
Yes, obviously.
I think the granularity of access controls is an aspect of security.
I think
* Andrew Dunstan (and...@dunslane.net) wrote:
> Josh Berkus wrote:
>> So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
>> features *except* row-level security, would it still be useful to the
>> SELinux community?
>>
>> I think we're just not going to work out the headache
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
around row-level secu
On Fri, Jan 30, 2009 at 5:37 PM, Josh Berkus wrote:
> Bruce,
>> Are you trying to make some kind of point?
>>
>
> Yeah, that we're certainly not doing any of this for 8.4.
>
> If we're going for radical new approaches for row-level, why not also look
> at the VIEWS approach? If we worked out the
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
around row-level security in time for 8.4,
Josh Berkus wrote:
> Bruce,
>
> > Are you trying to make some kind of point?
> >
>
> Yeah, that we're certainly not doing any of this for 8.4.
>
> If we're going for radical new approaches for row-level, why not also
> look at the VIEWS approach? If we worked out the same problems we need
>
Bruce,
Are you trying to make some kind of point?
Yeah, that we're certainly not doing any of this for 8.4.
If we're going for radical new approaches for row-level, why not also
look at the VIEWS approach? If we worked out the same problems we need
to fix for Bernd's patch, using automate
Bruce Momjian wrote:
> Josh Berkus wrote:
>> Bruce Momjian wrote:
>>> Josh Berkus wrote:
> Yea, it would take some work but it is an idea.
It's *an* idea,yes. But it introduces as many (or more) problems than
it solves.
>>> Ah, but my problems might be easier solved than the row-lev
Josh Berkus wrote:
> Bruce Momjian wrote:
> > Josh Berkus wrote:
> >>> Yea, it would take some work but it is an idea.
> >> It's *an* idea,yes. But it introduces as many (or more) problems than
> >> it solves.
> >
> > Ah, but my problems might be easier solved than the row-level permission
> > p
Bruce Momjian wrote:
Josh Berkus wrote:
Yea, it would take some work but it is an idea.
It's *an* idea,yes. But it introduces as many (or more) problems than
it solves.
Ah, but my problems might be easier solved than the row-level permission
problems. ;-)
Or might not. Multi-partition i
Josh Berkus wrote:
>
> > Yea, it would take some work but it is an idea.
>
> It's *an* idea,yes. But it introduces as many (or more) problems than
> it solves.
Ah, but my problems might be easier solved than the row-level permission
problems. ;-)
--
Bruce Momjian http://momjian.u
Yea, it would take some work but it is an idea.
It's *an* idea,yes. But it introduces as many (or more) problems than
it solves.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Joshua Brindle wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Gregory Stark writes:
> >>> I don't think partitioning is really the same thing as row-level
> >>> security.
> >> Of course not, but it seems to me that it can be used to accomplish most
> >> of the same practical use-cases. Th
> > I don't think partitioning is really the same thing as row-level security.
>
> Of course not, but it seems to me that it can be used to accomplish most
> of the same practical use-cases. The main gripe about doing it via
> partitioning is that the user's nose gets rubbed in the fact that the
Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark writes:
I don't think partitioning is really the same thing as row-level
security.
Of course not, but it seems to me that it can be used to accomplish most
of the same practical use-cases. The main gripe about doing it via
partitioning is th
Robert Haas writes:
> I'm wondering if this problem could be solved with a sort of
> mark-and-sweep garbage collection:
>...
> Then you can write something which goes through and sets all the rows
> to false and then visits every row of every table in the database and
> forces OID lookups on the
On Wed, Jan 28, 2009 at 9:49 PM, KaiGai Kohei wrote:
> IIRC, 0racle or M$ has a patent to rewrite WHERE clause for security
> purpose, so Tom suggested it should be implemented using a hook
> deployed within executor.
Yes, it was Oracle. There are a couple newer revisions, but they're all
base
Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane wrote:
Hmm. If that's the expected application environment then the patch as
proposed has fatal performance problems anyway, for lack of a way to
get rid of no-longer-referenced pg_security rows. We had been le
FYI, I have created a wiki page that summerizes the SE-PostgreSQL
information we have gathered so far:
http://wiki.postgresql.org/wiki/SEPostgreSQL-patch
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is
Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark writes:
I don't think partitioning is really the same thing as row-level
security.
Of course not, but it seems to me that it can be used to accomplish most
of the same practical use-cases. The main gripe about doing it via
partitioning is th
Robert Haas wrote:
> On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane wrote:
> > Hmm. If that's the expected application environment then the patch as
> > proposed has fatal performance problems anyway, for lack of a way to
> > get rid of no-longer-referenced pg_security rows. We had been led to
> > un
Tom Lane wrote:
> Gregory Stark writes:
> > I don't think partitioning is really the same thing as row-level
> > security.
>
> Of course not, but it seems to me that it can be used to accomplish most
> of the same practical use-cases. The main gripe about doing it via
> partitioning is that the
Robert Haas wrote:
My concern is that superuser is allowed to modify system catalog
by hand, like:
UPDATE pg_proc SET probin = '/tmp/malicious_library.so'
WHERE oid = ...;
It is logically same as ALTER FUNCTION.
Even if I remove a hook from simple_heap_(), it is necessary
to check que
Robert Haas wrote:
On Wed, Jan 28, 2009 at 10:15 PM, KaiGai Kohei wrote:
It seems to me reference-counter is more preferable than boolean,
at least. But it makes performance pain on writer access when it
is expanded to row-level security.
A reference counter will never work. You could easily
On Wed, Jan 28, 2009 at 10:15 PM, KaiGai Kohei wrote:
> It seems to me reference-counter is more preferable than boolean,
> at least. But it makes performance pain on writer access when it
> is expanded to row-level security.
A reference counter will never work. You could easily end up
serializin
Robert Haas wrote:
On Wed, Jan 28, 2009 at 9:27 PM, Stephen Frost wrote:
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
pg_security (which I really think out to be renamed to
pg_selinux_context or something, and make a new table if we someday
support Trusted Solaris or whatever).
Err,
> My concern is that superuser is allowed to modify system catalog
> by hand, like:
>
> UPDATE pg_proc SET probin = '/tmp/malicious_library.so'
> WHERE oid = ...;
>
> It is logically same as ALTER FUNCTION.
>
> Even if I remove a hook from simple_heap_(), it is necessary
> to check queries
On Wed, Jan 28, 2009 at 9:27 PM, Stephen Frost wrote:
> Robert,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> pg_security (which I really think out to be renamed to
>> pg_selinux_context or something, and make a new table if we someday
>> support Trusted Solaris or whatever).
>
> Err, this d
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane wrote:
Hmm. If that's the expected application environment then the patch as
proposed has fatal performance problems anyway, for lack of a way to
get rid of no-longer-referenced pg_security rows. We had been led to
understand that t
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> I agree that that's no good.
As do I.
> My concern is that superuser is allowed to modify system catalog
> by hand, like:
>
> UPDATE pg_proc SET probin = '/tmp/malicious_library.so'
> WHERE oid = ...;
That UPDATE still goes through permissio
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:34 PM, Tom Lane wrote:
As an example, the present patch imagines that it will have adequate
control over inserts by putting hooks into simple_heap_insert and the
(rather small number of) places that call heap_insert directly. But
there are dozens of
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane wrote:
Then you can write something which goes through and sets all the rows
to false and then visits every row of every table in the database and
forces OID lookups on the security ID of each. When you get done, any
rows that still
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> pg_security (which I really think out to be renamed to
> pg_selinux_context or something, and make a new table if we someday
> support Trusted Solaris or whatever).
Err, this doesn't really make sense if we're doing row-level security,
that's
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Obviously, we cannot make clear state of the row-level access
> controls by the date of v8.4 freeze.
Indeed, I have to agree that's where things are headed, which is
certainly unfortunate but I think it's good that we were able to provide
som
> I found a proverbial phrase in my dictionaly:
> Between two stools you fall to the ground.
LOL. I like that one - and it's very apt.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane wrote:
> Hmm. If that's the expected application environment then the patch as
> proposed has fatal performance problems anyway, for lack of a way to
> get rid of no-longer-referenced pg_security rows. We had been led to
> understand that there wouldn't
On Wed, Jan 28, 2009 at 6:34 PM, Tom Lane wrote:
> As an example, the present patch imagines that it will have adequate
> control over inserts by putting hooks into simple_heap_insert and the
> (rather small number of) places that call heap_insert directly. But
> there are dozens of calls of simp
Obviously, we cannot make clear state of the row-level access
controls by the date of v8.4 freeze.
I agree the row-level access controls can be separated and
postponed to v8.5 development cycle.
So, I'll cut off a few part of previous patches for v8.4.
Stephen Frost gave me a guideline about wha
Andrew Dunstan wrote:
Tom Lane wrote:
As an example, the present patch imagines that it will have adequate
control over inserts by putting hooks into simple_heap_insert and the
(rather small number of) places that call heap_insert directly. But
there are dozens of calls of simple_heap_insert an
Tom Lane wrote:
Joshua Brindle writes:
In reality it isn't, unless postgres won't mind thousands of
partitions being made. In the military/gov implementations BLP lets
you have hierarchical levels and non-hierarchical categories. Since I
linked to an article about it upthread I assumed everyone
Good morning, I started to follow the discussion.
(Time difference is unconfortable for me!)
>> adding SELinux support for the existing levels of access control in PG
>
> is
>
> - table/column level access controls
> - permission checks on database login
> - permission checks on function invocat
Joshua Brindle writes:
> In reality it isn't, unless postgres won't mind thousands of
> partitions being made. In the military/gov implementations BLP lets
> you have hierarchical levels and non-hierarchical categories. Since I
> linked to an article about it upthread I assumed everyone
> particip
Tom Lane wrote:
As an example, the present patch imagines that it will have adequate
control over inserts by putting hooks into simple_heap_insert and the
(rather small number of) places that call heap_insert directly. But
there are dozens of calls of simple_heap_insert and no way for the
func
Robert Haas writes:
> I'm not clear that I understand why it would be necessary for
> row-level security to touch every part of the code.
OK, I admit it's not "every" part, just every place that fetches,
inserts, updates, or deletes tuples. There are quite a few ;-)
As an example, the present p
Joshua Brindle wrote:
> Nonetheless, this conversation seems moot now that Tom has walled off
> and won't even discuss row-level access controls.
I think that's a bit of an overstatement.
He says he's against them[1] and he says that they are the sticking
point on this patch[2], and that they bre
Tom Lane writes:
> I don't believe I will ever think that row-level checks are a good idea; as
> long as those are in the patch I will vote against applying it.
I think we're conflating two behaviours here.
The data hiding behaviour clearly changes the semantics of queries in ways
that make a
Ron Mayer wrote:
Stephen Frost wrote:
And, just to go full circle, row-level access controls are exactly what
the other enterprise RDBMSs have and is what is used in these security
circles today. One of the major issues, as I understand it, is to be
able to use stock applications with multiple
Stephen Frost wrote:
> And, just to go full circle, row-level access controls are exactly what
> the other enterprise RDBMSs have and is what is used in these security
> circles today. One of the major issues, as I understand it, is to be
> able to use stock applications with multiple security lev
Joshua Brindle wrote:
> Tom Lane wrote:
>> Joshua Brindle writes:
>>> I'm not sure how much it would cut to remove row level access
>>> controls, but I do have some points here. To me, row level access
>>> controls are the most important part, this is the feature that lets us
>>> put secret and to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> For me, the row-level access controls are really the sticking point.
> There is absolutely nothing you can say that will convince me that they
> don't break SQL in fundamental ways, and I also don't believe that it's
> going to be possible to implement them
On Wed, Jan 28, 2009 at 3:58 PM, Tom Lane wrote:
> Andrew Sullivan writes:
>> On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote:
>>> The costs are nil for people who don't want this feature.
>
>> That's also false, because developers who don't care about the feature
>> have to contin
Sorry for top-posting and avoiding to paste online doc URL.
Joshua, you sound like you're missing an important point. Sorry for
misunderstanding if that's not true.
Partitioning is supported in a way that a query does not need to know
about it, be it a SELECT, INSERT, UPDATE or DELETE. And
Andrew Sullivan writes:
> On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote:
>> The costs are nil for people who don't want this feature.
> That's also false, because developers who don't care about the feature
> have to continue to maintain it as part of the system. If maintenance
On Wed, Jan 28, 2009 at 01:49:21PM -0500, Joshua Brindle wrote:
> use. The people that need them understand the ramifications of row
> filtering and the absence of inaccessible rows won't be surprising.
I wish there was even a little bit of evidence that users of a
security system may be relied u
Gregory Stark writes:
> I don't think partitioning is really the same thing as row-level
> security.
Of course not, but it seems to me that it can be used to accomplish most
of the same practical use-cases. The main gripe about doing it via
partitioning is that the user's nose gets rubbed in the
Joshua Brindle writes:
> partitions don't help because, once again, the application would be making the
> determination about which partition to query.
Not necessarily since the database can be programmed to automatically put the
records into the right partition. Right now it's a pain but we're
Tom Lane wrote:
Joshua Brindle writes:
I'm not sure how much it would cut to remove row level access
controls, but I do have some points here. To me, row level access
controls are the most important part, this is the feature that lets us
put secret and top secret data in the same table and use
Joshua Brindle writes:
> I'm not sure how much it would cut to remove row level access
> controls, but I do have some points here. To me, row level access
> controls are the most important part, this is the feature that lets us
> put secret and top secret data in the same table and use the clients
KaiGai Kohei wrote:
> Stephen Frost wrote:
>> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>>> So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable.
>>> If vanilla PostgreSQL become to check ACLs on tables, independent
>>> from views, do you think it is acceptable?
>> Well, just to b
Even if I implement SE-PostgreSQL as a loadable module, core
PostgreSQL has to provide proper hooks in strategic points and
facilities to manage security attribute (pg_security system catalog
and security_label system column).
If you require to implement it without these facilities, I think
it is
KaiGai Kohei wrote:
>> I'm not sure about KaiGai's feelings on this, but it strikes me that
>> adding SELinux support for the existing levels of access control in PG
>> might be straight-forward and small enough to include for 8.4 and would
>> show some commitment to this approach of "do it for PG,
Stephen Frost wrote:
> * KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
>> So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable.
>> If vanilla PostgreSQL become to check ACLs on tables, independent
>> from views, do you think it is acceptable?
>
> Well, just to be clear, ACLs are checke
> Text represented security attribute is the most common format
> for any other security mechanism also.
> (For example, T-SOL also have its text representation.)
> In addition, TEXT is the most flexible format. If any other
> feature want to handle it as an array, it can be stored as
> a text repr
Robert Haas wrote:
I haven't read the code, but from reading the docs, I have a feeling
that right now the answer to both questions are NO, which means it
doesn't really have a lot of value. One example of this is the
pg_security system catalog. The catalog representation you're
proposing is pr
> That being said, I'd think that if we do need different semantics from
> that for SE-PostgreSQL, we could implement it using a GUC or similar to
> keep the current behavior as well allow the SE-PostgreSQL behavior.
I don't think a GUC is what you need because you need both behaviors
simultaneous
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
> So, I cannot believe refactoring pg_xxx_aclcheck() is not acceptable.
> If vanilla PostgreSQL become to check ACLs on tables, independent
> from views, do you think it is acceptable?
Well, just to be clear, ACLs are checked on tables under views, but
t
> However, we have to make clear whether the PGACE architecture
> is incorrect, or not, at first.
> I think the name of PGACE is not important, but it is necessary
> to make SELinux's decision in similar strategic point in finally.
I've been thinking about this issue as well. I think a framework
Sorry for long description again.
Peter Eisentraut wrote:
I have re-reviewed the SE-PostgreSQL patch set. I don't want to talk
about here whether the security model is appropriate, how foreign keys
are to be handled etc. I want to discuss that I really don't like the
architecture of this pat
1 - 100 of 101 matches
Mail list logo
