From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Identifying user-created objects |
Date: | 2020-03-04 09:02:17 |
Message-ID: | 87562339-1fc9-ddf5-8d40-eb7620e35ab2@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020/03/04 17:05, Masahiko Sawada wrote:
> On Wed, 4 Mar 2020 at 16:43, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>
>>
>>
>> On 2020/02/05 20:26, Masahiko Sawada wrote:
>>> Hi,
>>>
>>> User can create database objects such as functions into pg_catalog.
>>> But if I'm not missing something, currently there is no
>>> straightforward way to identify if the object is a user created object
>>> or a system object which is created during initdb. If we can do that
>>> user will be able to check if malicious functions are not created in
>>> the database, which is important from the security perspective.
>>
>> The function that you are proposing is really enough for this use case?
>> What if malicious users directly change the oid of function
>> to < FirstNormalObjectId? Or you're assuming that malicious users will
>> never log in as superuser and not be able to change the oid?
>
> That's a good point! I'm surprised that user is allowed to update an
> oid of database object. In addition, surprisingly we can update it to
> 0, which in turn leads the assertion failure:
Since non-superusers are not allowed to do that by default,
that's not so bad? That is, to avoid such unexpected change of oid,
admin just should prevent malicious users from logging in as superusers
and not give the permission on system catalogs to such users.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-03-04 09:03:40 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
Previous Message | Julien Rouhaud | 2020-03-04 09:01:00 | Re: Collation versioning |