Re: sepgsql contrib module - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: sepgsql contrib module
Date
Msg-id AANLkTingSZ7LRTJRiCKG7_uDkh9ORFDJaL+2TTWYvmAb@mail.gmail.com
Whole thread Raw
In response to Re: sepgsql contrib module  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2011/1/22 Robert Haas <robertmhaas@gmail.com>:
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> For that matter, I wonder what happens with regular function
>>> permissions.  If the plan inlines the function and then somebody goes
>>> and changes the permission on the function and makes it SECURITY
>>> DEFINER, what happens?
>>
>> ALTER FUNCTION is supposed to cause plan invalidation in such a case.
>> Not sure if GRANT plays nice with that though.
>
> And in the case of SE-Linux, this could get changed from outside the
> database.  Not sure how to handle that.  I guess we could just never
> inline anything, but that might be an overreaction.
>
We can have two standpoints.

The one is that functions are once allowed to execute on the plan time,
so we don't need to check it on execution time, and inlined.
Thus, the function shall be melted.

The other is that permission checks should be done in execution time,
so we never allows to inline functions anyway.
This attitude is more strict, but mostly overreaction.

In my opinion, the later one is more correct standpoint when we put
the highest priority on security.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sepgsql contrib module
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI and Hot Standby