Re: Identifying user-created objects
От | Masahiko Sawada |
---|---|
Тема | Re: Identifying user-created objects |
Дата | |
Msg-id | CA+fd4k5DZ7dBBuqDVEFXH2REubrwU-=RnMau+MsF6EVmQmhAWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Identifying user-created objects (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Identifying user-created objects
(Fujii Masao <masao.fujii@oss.nttdata.com>)
|
Список | pgsql-hackers |
On Wed, 4 Mar 2020 at 18:57, Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > > > > On 2020/03/04 18:36, Masahiko Sawada wrote: > > 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. > > Yes. But I'm sure that DBA has already considered the measures > againt such threads. Otherwise malicious users can do anything > more malicious rather than changing oid. Agreed. So that's not a serious problem in practice but we cannot say the checking by pg_is_user_object() is totally enough for checking whether malicious object exists or not. Is that right? Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: