Robert Haas wrote:
2009/4/21 KaiGai Kohei kai...@ak.jp.nec.com:
Robert, currently I could not find semantics breaks in your suggestion.
I plan to update SE- implementation to skip checks during foreign-key
constraints and add a new SE- permission: reference which allows
to set up
KaiGai Kohei wrote:
Robert Haas wrote:
On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
So in this situation -- I suspect, if any SELinux people want to pipe
up to tell me whether I'm on the right
2009/4/21 KaiGai Kohei kai...@ak.jp.nec.com:
Robert, currently I could not find semantics breaks in your suggestion.
I plan to update SE- implementation to skip checks during foreign-key
constraints and add a new SE- permission: reference which allows
to set up fereign-keys.
Sounds good! I
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
The vanilla access control mechanism switches the current userid, and it
enables
to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model
does not
have a concept of
KaiGai Kohei wrote:
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
The vanilla access control mechanism switches the current userid, and it
enables
to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model
does not
have a concept of ownership.
Should I not read
On Mon, Apr 20, 2009 at 3:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It seems to me a quite ad-hoc idea.
That's rather a silly charge to be leveling when your own proposal is
such a horrid kluge as this one. As near as I can tell, you intend
that SELinux will be unable to prohibit SELECT FOR
Greg Stark st...@enterprisedb.com writes:
I think we're talking at cross purposes here. I think Kai Gai's
descriptions make sense if you start with a different set of
assumptions. The idea behind SELinux is that each individual object is
access controlled and each user has credentials which
Tom Lane t...@sss.pgh.pa.us writes:
Greg Stark st...@enterprisedb.com writes:
I think we're talking at cross purposes here. I think Kai Gai's
descriptions make sense if you start with a different set of
assumptions. The idea behind SELinux is that each individual object is
access controlled
On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
So in this situation -- I suspect, if any SELinux people want to pipe
up to tell me whether I'm on the right track -- the idea is that you
should be able to examine a user superficially and know for certain
whether he has the ability
KaiGai Kohei kai...@ak.jp.nec.com writes:
Heikki Linnakangas wrote:
Can't you have a SE-PostgreSQL policy like disallow ACL_UPDATE on table
X for user Y, except when current user is owner of X?
It seems to me a quite ad-hoc idea.
That's rather a silly charge to be leveling when your own
On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
So in this situation -- I suspect, if any SELinux people want to pipe
up to tell me whether I'm on the right track -- the idea is that you
should be
Gregory Stark wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Greg Stark st...@enterprisedb.com writes:
I think we're talking at cross purposes here. I think Kai Gai's
descriptions make sense if you start with a different set of
assumptions. The idea behind SELinux is that each individual object
Robert Haas wrote:
On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
So in this situation -- I suspect, if any SELinux people want to pipe
up to tell me whether I'm on the right track -- the idea is
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit
so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE
or SHARE.
Why should it discriminate between them?
Typically, we cannot set up a foreign-key which
KaiGai Kohei wrote:
However, ACL_UPDATE and ACL_SELECT_FOR_UPDATE internally shares same bit
so SE-PostgreSQL cannot discriminate between UPDATE and SELECT FOR UPDATE
or SHARE.
Why should it discriminate between them?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
KaiGai Kohei kai...@kaigai.gr.jp writes:
Heikki Linnakangas wrote:
Why should it discriminate between them?
Typically, we cannot set up a foreign-key which refers a primary-key within
read-only table from SELinux's viewpoint.
The vanilla access control mechanism switches the current userid,
Tom Lane wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
Heikki Linnakangas wrote:
Why should it discriminate between them?
Typically, we cannot set up a foreign-key which refers a primary-key within
read-only table from SELinux's viewpoint.
The vanilla access control mechanism switches
KaiGai Kohei wrote:
We have an another approach that defines ACL_SELECT_FOR_SHARE as
an alias of ACL_SELECT, and applies it on SELECT FOR SHARE statement.
(Needless to say, the targets are already listed, so it might not necessary
to put a ACL_SELECT_FOR_SHARE bit explicitly.)
That's even
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
IMHO the only sane change would be to introduce a new
ACL_SELECT_FOR_SHARE permission for SELECT FOR SHARE.
This might be worth doing ...
That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.
... but this argument
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
Currently, the ACL_SELECT_FOR_UPDATE privilege is defined as an alias
of ACL_UPDATE as follows:
at src/include/nodes/parsenodes.h:
:
/* Currently, SELECT ... FOR UPDATE/FOR SHARE requires UPDATE privileges */
#define
KaiGai Kohei kai...@ak.jp.nec.com writes:
Heikki Linnakangas wrote:
What's the point of doing SELECT FOR UPDATE if you're not actually going
to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
UPDATE seems useless.
I wonder why SELECT FOR UPDATE need ACL_UPDATE, although
Tom Lane wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
Heikki Linnakangas wrote:
What's the point of doing SELECT FOR UPDATE if you're not actually going
to UPDATE the row? Having separate permissions for SELECT FOR UPDATE and
UPDATE seems useless.
I wonder why SELECT FOR UPDATE need
Currently, the ACL_SELECT_FOR_UPDATE privilege is defined as an alias
of ACL_UPDATE as follows:
at src/include/nodes/parsenodes.h:
:
/* Currently, SELECT ... FOR UPDATE/FOR SHARE requires UPDATE privileges */
#define ACL_SELECT_FOR_UPDATE ACL_UPDATE
:
It is
KaiGai Kohei wrote:
Currently, the ACL_SELECT_FOR_UPDATE privilege is defined as an alias
of ACL_UPDATE as follows:
at src/include/nodes/parsenodes.h:
:
/* Currently, SELECT ... FOR UPDATE/FOR SHARE requires UPDATE privileges */
#define ACL_SELECT_FOR_UPDATE ACL_UPDATE
26 matches
Mail list logo
