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 weeks ago.
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com 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,
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
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
On 1/30/09 5:43 PM, Josh Berkus j...@agliodbs.com 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
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
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 the
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 addition, it
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
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
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 sense,
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
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
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
* 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,
* 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 system column,
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 assigned to them
due
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
and
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost sfr...@snowman.net 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
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 should not be
Robert Haas wrote:
On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost sfr...@snowman.net 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
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 attribute for
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
* 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. if
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
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,
Joshua Brindle wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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.
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:
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 br...@momjian.us
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
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
problems. ;-)
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-level permission
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
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
to fix for
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,
On Fri, Jan 30, 2009 at 5:37 PM, Josh Berkus j...@agliodbs.com 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
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
* 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-inducing
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
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
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 pgaceHooks.c
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
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 we did. It
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
Robert Haas robertmh...@gmail.com 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
Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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
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 there
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 patch. I have said this before in previous review
rounds,
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
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 of
* 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
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
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
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
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 checked on
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, add
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:
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
Joshua Brindle met...@manicmethod.com 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
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com 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
Joshua Brindle met...@manicmethod.com 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
Gregory Stark st...@enterprisedb.com 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
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
Andrew Sullivan a...@crankycanuck.ca 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.
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
On Wed, Jan 28, 2009 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Sullivan a...@crankycanuck.ca 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
* 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
Joshua Brindle wrote:
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com 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
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 levels
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
Tom Lane t...@sss.pgh.pa.us 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
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
Robert Haas robertmh...@gmail.com 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
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
Joshua Brindle met...@manicmethod.com 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
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 invocation
-
Tom Lane wrote:
Joshua Brindle met...@manicmethod.com 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
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
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
On Wed, Jan 28, 2009 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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
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:
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
some
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
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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,
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us 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
* 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 permissions
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jan 28, 2009 at 9:27 PM, Stephen Frost sfr...@snowman.net 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).
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 from
Robert Haas wrote:
On Wed, Jan 28, 2009 at 9:27 PM, Stephen Frost sfr...@snowman.net 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
On Wed, Jan 28, 2009 at 10:15 PM, KaiGai Kohei kai...@ak.jp.nec.com 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
Robert Haas wrote:
On Wed, Jan 28, 2009 at 10:15 PM, KaiGai Kohei kai...@ak.jp.nec.com 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
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
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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
Bruce Momjian wrote:
Tom Lane wrote:
Gregory Stark st...@enterprisedb.com 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
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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+
Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Jan 28, 2009 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us 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
1 - 100 of 101 matches
Mail list logo
