Robert Haas wrote:
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane wrote:
If I have to break up the recipe with annotations like "run this part as
root" and then "these commands no longer need root", I don't think
that's going to be an improvement over either of the above.
Fair enough, I'm not g
Stephen Frost wrote:
Tom,
The
proposals to make SEPostgres drive regular SQL permissions never came
out of anyone from that side, they were proposed by PG people looking
for a manageable first step.
I do not believe this to be accurate. Josh, were you able to find any
public documentation
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last night I managed to get a great
group o
Joshua Brindle wrote:
Greg Smith wrote:
It's funny; we started out this CommitFest with me scrambling to find
someone, anyone, willing to review the latest SE-PostgreSQL patch,
knowing it was a big job and few were likely to volunteer. Then
schedules lined up just right, and last ni
Stephen Frost wrote:
KaiGai,
I do think that, technically, there's no reason we couldn't allow for
multiple "only-more-restrictive" models to be enabled and built in a
single binary for systems which support it. As such, I would make those
just "#if defined()" rather than "#elif". Let it be
So the security model has been looked at, though not the implementation and we
do have a community of developers, users and customers interested in this work.
Joshua Brindle
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the security backend and determining whether it
matches the security model we agreed on, but the hook placement is just as
important since a misplaced or missing hook will allow access that should not be
granted.
Joshua Brindle
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Tom Lane wrote:
Ron Mayer writes:
Tom Lane wrote:
The second problem is that we're not sure it's really the right thing,
because we have no one who is competent to review the design from a
security standpoint.
Are we underestimating Kaigai Kohei?
Perhaps he walks on water, but still I'd l
Tom Lane wrote:
Joshua Brindle writes:
http://marc.info/?l=selinux&m=115762285013528&w=2
Is the original discussion thread for the security model used in the
sepostgresql work. Hopefully you'll see some of the evidence you speak of there.
Thanks for the link. I took a look
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
SEPostgres seems qualitatively different to me, though. I think PG
people have avoided reviewing it because (a) they weren't interested in
it and (b) they knew they were unqualified to review it.
Meanwhile it's emerging that the selin
Josh Berkus wrote:
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like
WHERE
pg_accessible(tab).
The idea is for the level of informa
Tom Lane wrote:
Josh Berkus writes:
Stephen Frost wrote:
It does seem weird to simply omit records rather than throw an error
The presumption is that if you know the data exists but can't access it
directly, you'll use indirect methods to derive what it is. But if you
don't even know it ex
Josh Berkus wrote:
Josh,
We do not consider that a short coming, anyone who needs to hide
existence of files needs to set up their directory structure to
disallow read/search/create on the directories they aren't allowed to
discover filenames in. Polyinstanciation can also address this issue.
Tom Lane wrote:
Joshua Brindle writes:
Tom Lane wrote:
Right, which is why it's bad for something like a foreign key constraint
to expose the fact that the row does exist after all.
Once again, this is not an issue for us.
Yes it is an issue; claiming it isn't doesn't m
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
This seems to me to be exactly parallel to deciding that SELinux should
control only table/column permissions within SQL; an approach that would
be enormously less controversial, less expensive, and more reliable than
what SEPostgres tr
Ron Mayer wrote:
Stephen Frost wrote:
* Gregory Stark (st...@enterprisedb.com) wrote:
It does seem weird to simply omit records rather than throw an error and
require the user to use a where clause, even if it's something like WHERE
pg_accessible(tab).
It is weird from an SQL perspective, I ag
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace part,
this is where the core interfaces to the security backends, and you'll
see a rowacl backend and an sepgsql backend.
Right, guess it wasn
Tom Lane wrote:
Simon Riggs writes:
On Tue, 2009-01-27 at 13:57 -0500, Joshua Brindle wrote:
Josh Berkus wrote:
Hmmm. Why try to hide individual rows in tables then? That would seem
not in keeping with the filesystem policies.
Because rows have data in them. It is analogous to not allowing
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that
Tom Lane wrote:
Stephen Frost writes:
Personally, I think it'd be terrible to implement the suggestion that
started this sub-thread since it breaks with what is currently done
elsewhere and what the users of this feature would expect.
Upthread we were being told that this patch breaks new gro
Devrim GÜNDÜZ wrote:
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote:
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres.
FWIW, as you know, sepostgresql is alrea
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
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 an
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 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
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
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
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
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
KaiGai Kohei wrote:
KaiGai Kohei wrote:
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1530.patch
[3/5]
http://sepgsql.googlecod
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout wrote:
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being ac
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 go
Tom Lane wrote:
Martijn van Oosterhout writes:
I'm asking because from my position it looks like KaiGai is being
simultaneously told "you patch is too big, make it smaller" and "your
patch is not complete (with respect to some metric), make it bigger"
and we need to define a middle ground if we
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
Ron Mayer wrote:
Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you
waiting for a good feeling?
Joshua - if you're still associated with Tresys - could someone
who could speak for that company say what they think about this
project? The seem qui
Greg Stark wrote:
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
I am capable of speaking for Tresys in this matter. We are very interested
in this work and our US DoD customers need the capabilities that this
project adds (assuming row level access controls are a possibility).
I&#
Greg Stark wrote:
On Tue, Jul 21, 2009 at 3:20 PM, Joshua Brindle wrote:
Backing up from KaiGai's description a bit, basically what this is needed
for is storing multilevel data in a single db instance.
For example, you have people logging in from different classifications
(unclass, s
Greg Stark wrote:
On Tue, Jul 21, 2009 at 4:24 PM, Joshua Brindle wrote:
You also snipped the other scenario I had where row based access control
isn't required but column level and stored procedure level are.
Well we already have column level and stored procedure privi
38 matches
Mail list logo
