Re: Identifying user-created objects

From: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Identifying user-created objects
Date: 2020-03-05 09:06:26
Message-ID: CA+fd4k75aUOSb1cEhF3hKd-t9xPfZAD2Sd6uTvypmQQo-9EN3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 5 Mar 2020 at 16:36, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Thu, 5 Mar 2020 15:21:49 +0900, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote in
> > > > I don't come up with another use cases but, anyway, I think we need to
> > > > clarify the scope of the feature.
> > >
> > > Agreed. Also we would need to consider that the existing approach
> > > (e.g., checking whether the object is defined under pg_catalog or not,
> > > or seeing pg_stat_user_functions, _indexes, and _tables) is enough
> > > for the use cases. If enough, new function might not be necessary.
> > > If not enough, we might also need to reconsider the definitions of
> > > pg_stat_user_xxx after considering the function.
> > >
> >
> > Originally the motivation of this feature is that while studying PCI
> > DSS 2.2.5 I thought that a running PostgreSQL server is not able to
> > prove that there is no malicious function in database. PCI DSS 2.2.5
> > states "Remove all unnecessary functionality, such as scripts,
> > drivers, features, subsystems, file systems, and unnecessary web
> > servers." If we want to clarify unnecessary or malicious functions we
> > can check public schema and user schema but once a function is created
> > on pg_proc we cannot distinguish whether it's a built-in (i.g. safe)
> > function or not. I totally agree that if malicious someone logs in as
> > a superuser he/she can do anything more serious than changing catalog
> > contents but I wanted to have a way to prove soundness of running
> > database.
>
> Thanks for the elaboration. It doesn't seem to me as the
> resposibility of PostgreSQL program. The same can be said to OSes.
>
> I think the section is not saying that "keep you system only with
> defaultly installed components", but "remove all features unncecessary
> to your system even if it is defaultly installed as far as you can".

Agreed.

> And whether A system is needing a feature or not cannot be the matter
> of PostgreSQL or OSes.
>
> So you need to remove some system-admistrative functions if you know
> it is not required by your system in order to comform the
> requirement. But they would be "non-user-defined" objects.

I think normally users don't want to remove built-in functions because
they think these functions are trusted and it's hard to restore them
when they want later. So I thought user want to search functions that
is unnecessary but not a built-in function.

Regards,

--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Juan José Santamaría Flecha 2020-03-05 09:09:31 Re: PG_COLOR not mentioned in docs of vacuumlo, oid2name and pgbench
Previous Message Amit Kapila 2020-03-05 08:45:34 Re: logical replication empty transactions