Re: sepgsql contrib module

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, PgHacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sepgsql contrib module
Date: 2011-01-21 15:41:23
Message-ID: AANLkTingSZ7LRTJRiCKG7_uDkh9ORFDJaL+2TTWYvmAb@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/1/22 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Fri, Jan 21, 2011 at 9:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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(at)kaigai(dot)gr(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-21 15:43:12 Re: More detailed auth info
Previous Message Robert Haas 2011-01-21 15:40:26 Re: More detailed auth info