Robert Haas wrote:
> 2009/4/21 KaiGai Kohei :
>> 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.
>
> Sou
2009/4/21 KaiGai Kohei :
> 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 hope that works
KaiGai Kohei wrote:
> Robert Haas wrote:
>> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
>> 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 trac
Robert Haas wrote:
> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
> 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
>
Gregory Stark wrote:
> Tom Lane writes:
>
>> Greg Stark 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 an
On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
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 able to examin
KaiGai Kohei 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 proposal is
such
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 abili
Tom Lane writes:
> Greg Stark 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 wh
Greg Stark 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 grant access to
> spe
On Mon, Apr 20, 2009 at 3:14 PM, Tom Lane 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 UPDATE becaus
KaiGai Kohei wrote:
> Tom Lane wrote:
>> KaiGai Kohei 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 t
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei 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 o
Tom Lane wrote:
> KaiGai Kohei 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 curre
KaiGai Kohei 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, and it
> enab
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
--
Sen
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
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas 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 for it is
Tom Lane wrote:
Heikki Linnakangas 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 for it is utter nonsense. FKs are n
Heikki Linnakangas 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
> into other tables that have a f
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
Tom Lane wrote:
> KaiGai Kohei 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_UPDA
KaiGai Kohei 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 the statemen
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 */
>> #def
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_UP
25 matches
Mail list logo
