On Wed, 4 Mar 2020 at 18:02, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2020/03/04 17:05, Masahiko Sawada wrote:
> > On Wed, 4 Mar 2020 at 16:43, Fujii Masao <masao.fujii@oss.nttdata.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.
>
I think there is still insider threats. As long as we depend on
superuser privilege to do some DBA work, a malicious DBA might be able
to log in as superuser and modify oid.
This behavior is introduced in PG12 where we made oid column
non-system column. A table having oid = 0 is shown in pg_class but we
cannot drop it.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
