Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p46IO-0007BT-8G for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Dec 2022 20:18:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p46IN-0005RR-20 for pgsql-hackers@arkaria.postgresql.org; Sat, 10 Dec 2022 20:18:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p46IM-0005RI-Kj for pgsql-hackers@lists.postgresql.org; Sat, 10 Dec 2022 20:18:02 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p46IH-0000ky-C1 for pgsql-hackers@lists.postgresql.org; Sat, 10 Dec 2022 20:18:01 +0000 Received: by mail-il1-x129.google.com with SMTP id j28so1563675ila.9 for ; Sat, 10 Dec 2022 12:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=N/sT3ov6KHDGh9c+gc5pTNYHb/Uq3bXV0JZXuoTSziU=; b=5SQORimAcfE+C0eF5MeZWyPba6JjDV0OkjUwnJY4rXd5LzcwEwJVZfeNnFsoSMSlRb LgTN/Io4+M/UV34TiTkGTQE9SGnyX9WvvpijXxf9ubrktqzmzPCASmA1COMp9dU9AGa8 JRT4Ys0Y32g3EB9Rv7yBXCQJlaQ/aymAluP6bx4DuHFPiZWWaOHpPyiQhh9jQkrIFwWl jNAi+7CvQQGeKSmj6HVrDDrj8C1n2ZQqSN1UN/SlmFYeJ2tCSNUYDSc52gTK9MRu1dtn 2qAvBS17OS377NogDbOqz7cxB152nBUcOMgqNHS4VoIK6vfP6iw3EbAPdMb7CjCu1SUa 1Udw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N/sT3ov6KHDGh9c+gc5pTNYHb/Uq3bXV0JZXuoTSziU=; b=WXGf9ANXXjwhjhTHfPaJD+3uUQhGJ3xFTdcdDunI9HICx9nbBiB6+m3/tNKsaJGFPI NAPDxvTt7T4B1qBSrlKIhWQTfgHwGwDGDCtvZ4dDSasBJn4IB+eCxTNq3afBHMqIHUPb bLTkB9yvbJsYKa0OlauwrAHaVlBnOP/f/hM/Dk5TTCjgEJk1gEbErO81hpehDJhFlyrU 0dwLHJK6l29fdso6I9yZFfDYulblVRyWoDD8uj0xy2PKSYd7Gc48aqv3Dohz+yraianH 7Vt/2dX82dws8e4bvqsX2KO8KIOngGi3TlGAYuM9idnElHojuRyb905p+6X/5kSUF5If TPTg== X-Gm-Message-State: ANoB5pkWflWpQn6yZVtlDHpjcFC5bo89Okm5RHAu66yo3a7WKsOxu7v0 kCG95wqPdpCM0NA7+6tJiWeqdA== X-Google-Smtp-Source: AA0mqf5vFQossCjhEZzRwUO+5rtMk0mXMuIpwxOP81SPZhjkI2LJCQ7YWDkcJtXLRF1qzDx3Zi6wZw== X-Received: by 2002:a05:6e02:80b:b0:303:7f2:7c75 with SMTP id u11-20020a056e02080b00b0030307f27c75mr6096575ilm.12.1670703475264; Sat, 10 Dec 2022 12:17:55 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id k13-20020a92c9cd000000b003024a44cd95sm1572745ilq.34.2022.12.10.12.17.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Dec 2022 12:17:54 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id E4CA88002C0; Sat, 10 Dec 2022 14:17:53 -0600 (CST) Date: Sat, 10 Dec 2022 14:17:53 -0600 From: Justin Pryzby To: Amit Langote Cc: Alvaro Herrera , Ian Lawrence Barwick , Tom Lane , David Rowley , Greg Stark , Julien Rouhaud , pgsql-hackers@lists.postgresql.org Subject: Re: ExecRTCheckPerms() and many prunable partitions (checkAsUser) Message-ID: <20221210201753.GA27893@telsasoft.com> References: <20221129092708.uooopfzpiwrhgedl@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 29, 2022 at 10:37:56PM +0900, Amit Langote wrote: > 0002 contains changes that has to do with changing how we access > checkAsUser in some foreign table planning/execution code sites. > Thought it might be better to describe it separately too. This was committed as 599b33b94: Stop accessing checkAsUser via RTE in some cases Which does this in a couple places in selfuncs.c: if (!vardata->acl_ok && root->append_rel_array != NULL) { AppendRelInfo *appinfo; Index varno = index->rel->relid; appinfo = root->append_rel_array[varno]; while (appinfo && planner_rt_fetch(appinfo->parent_relid, root)->rtekind == RTE_RELATION) { varno = appinfo->parent_relid; appinfo = root->append_rel_array[varno]; } if (varno != index->rel->relid) { /* Repeat access check on this rel */ rte = planner_rt_fetch(varno, root); Assert(rte->rtekind == RTE_RELATION); - userid = rte->checkAsUser ? rte->checkAsUser : GetUserId(); + userid = OidIsValid(onerel->userid) ? + onerel->userid : GetUserId(); vardata->acl_ok = rte->securityQuals == NIL && (pg_class_aclcheck(rte->relid, userid, ACL_SELECT) == ACLCHECK_OK); } } The original code rechecks rte->checkAsUser with the rte of the parent rel. The patch changed to access onerel instead, but that's not updated after looping to find the parent. Is that okay ? It doesn't seem intentional, since "userid" is still being recomputed, but based on onerel, which hasn't changed. The original intent (since 553d2ec27) is to recheck the parent's "checkAsUser". It seems like this would matter for partitioned tables, when the partition isn't readable, but its parent is, and accessed via a view owned by another user? -- Justin