On Thu, May 26, 2022 at 1:50 AM Noah Misch <noah@leadboat.com> wrote:
> > I think what is happening here is that parse analysis of the index
> > expression is now being done as the owner of the table (already assigned
> > as limitedrole), as a consequence of the patch for CVE-2022-1552.
> > So basically, that patch has completely broken pg_dump's scheme for
> > when it can issue GRANTs. I'm not sure there is a simple fix :-(.
>
> Not too simple, no. The parts of DefineIndex() that execute user code
> (e.g. DefineIndex->ComputeIndexAttrs->CheckMutability) are interspersed with
> the parts that do permissions checks, like the one yielding $SUBJECT at
> DefineIndex->ComputeIndexAttrs->ResolveOpClass->LookupExplicitNamespace. My
> first candidate is to undo the userid switch before the ResolveOpClass() call
> and restore it after. My second candidate is to pass down the userid we want
> used for this sort of permissions check. Depending on the full list of call
> stacks reaching permissions checks, this could get hairy.
Why isn't the current behavior - i.e. failing with a permissions error
- correct? I mean I realize it's wrong in the sense that you can't
restore a dump you just took, but what about from a security
perspective? I'm not sure there's an actual problem, because it's the
superuser who is creating a new index here, and the superuser can do
as they wish, but the point of CVE-2022-1552 seems to be that
unprivileged users could induce the superuser to do things they
couldn't do themselves, and the consequence of preventing that seems
to be that things done as the superuser might sometimes fail because
the unprivileged user wouldn't have been able to do them, which is
what's happening here.
Now, I don't think it's an intrinsic problem if we have different
rules for different parts of the operation, and I guess that is what
you are proposing here, but it doesn't seem very clear which parts of
the operation ought to be subject to which rules, and why. Like,
what's the distinction, exactly, between "parts that do permissions
checks" and "parts that user code"? Under what circumstances, exactly,
do we need to use the table owner's permissions, and under what
circumstances the permissions of the user performing the operation?
--
Robert Haas
EDB: http://www.enterprisedb.com