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 1p5sh7-0004qi-Mi for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Dec 2022 18:10:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p5sh4-0001OV-SX for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Dec 2022 18:10:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5sh4-0001Nh-FW for pgsql-hackers@lists.postgresql.org; Thu, 15 Dec 2022 18:10:54 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p5sgx-0003Em-Iw for pgsql-hackers@postgresql.org; Thu, 15 Dec 2022 18:10:53 +0000 Received: by mail-pj1-x1033.google.com with SMTP id v13-20020a17090a6b0d00b00219c3be9830so3473212pjj.4 for ; Thu, 15 Dec 2022 10:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=23ZAICd9i3dyaKF4PdBp6Ya+o3hsfEVzMY/ArpRn7UU=; b=6HcRKytlQsPO7YaGWg/qHgPERU+/n+Dy/U3fTmMJLUWw9aK6iCEgbDX4ImOXt6km5d NQoLG8dVh9YknBoJ08M0fC8PnFy0cQO00lC0R46X9QUEeBTpyhrvA788HGhAhYK/hT43 6fNaDnk3CXoFksddYsfnwWgR+PIGlXDwa5EguELdSvN7VPJWypcLnkzK6T4qWZlRlbto hpO2l0HX1G2A6nD/As7eD3TqNsGnTEAcv7gTIbtTf5YbhW7nm1lmk0cZq45av5ym6TV5 OUiS9LZgRo6fOkFPwb0DQZxQ0BglCW1b+HhqV3XdIMdM8Mk1kQwylyD6OfIG1ZAghGa7 0zFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=23ZAICd9i3dyaKF4PdBp6Ya+o3hsfEVzMY/ArpRn7UU=; b=t5XQyNvW1FE+KDUdcqd+w9Ro/FHkgt4URedS1appiXQMVzyFMnr6/Mo9N+Wi6aFgKR APogr/+0t2boJ+Oggrtk/HkbbkDUbjZD3LwlHmsSGlALWr5YqEYs6DXFncEV1rUTW1vP vKT9QqhT3MNf6I+6gofQYLP007N++qrqE4He7Ab0bOiqQS585BtEc1T9xsuVQSqnr/0r E6ntXspwmGe4/tidsOe8+eQGR6LljazMg4UtWCMjmkINijP6bO3lP9A0fVOw4DpbXZ4I rgdaUFHE0qMAktQHsGc441D+43iUUIOb6dGqoBD9blmFUZY8ekOy2goMvad18+XoybJH YWHQ== X-Gm-Message-State: ANoB5pm/4psfnT6v9Xsm1mSlfHoY7pFYop/kSbP3d33l9YP6V6kK0FQz v/piYGF3h7TBljZRRabKShr4yg== X-Google-Smtp-Source: AA0mqf4iZ+B4JsqOQ4pYIRNdjv4c9W7uMB48jPVyP4AX3zwFc7+TdCqIAxhJnGrFWZgA6+DdZJ8vqA== X-Received: by 2002:a17:902:9003:b0:190:cf2e:391f with SMTP id a3-20020a170902900300b00190cf2e391fmr11379875plp.31.1671127846233; Thu, 15 Dec 2022 10:10:46 -0800 (PST) Received: from jeff-laptop.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id h8-20020a170902680800b00172f6726d8esm4109685plk.277.2022.12.15.10.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 10:10:45 -0800 (PST) Message-ID: <295e86c7aeafb8e2623f8eccdc846855bf2c7e0c.camel@j-davis.com> Subject: Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX From: Jeff Davis To: Pavel Luzanov , Justin Pryzby Cc: Nathan Bossart , pgsql-hackers@postgresql.org Date: Thu, 15 Dec 2022 10:10:43 -0800 In-Reply-To: References: <20221208183707.GA55474@nathanxps13> <210dc2cc663934f8b463e4effa9af86225e46ce4.camel@j-davis.com> <20221210204109.GA197392@nathanxps13> <20221212200427.GA448418@nathanxps13> <20221212210136.GA449764@nathanxps13> <20221214032332.GA671806@nathanxps13> <8f7172da-2b58-3bd0-97ae-5126e2a7970c@postgrespro.ru> <20221214221140.GA1153@telsasoft.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2022-12-15 at 12:31 +0300, Pavel Luzanov wrote: > I think the approach that Nathan implemented [1] for TOAST tables > in the latest version can be used for partitioned tables as well. > Skipping the privilege check for partitions while working with > a partitioned table. In that case we would get exactly the same > behavior > as for INSERT, SELECT, etc privileges - the MAINTAIN privilege would=20 > work for > the whole partitioned table, but not for individual partitions. There is some weirdness in 15, too: create user foo; create user su superuser; grant all privileges on schema public to foo; \c - foo create table p(i int) partition by range (i); create index p_idx on p (i); create table p0 partition of p for values from (0) to (10); \c - su create table p1 partition of p for values from (10) to (20); \c - foo -- possibly weird because the 15 inserts into p1 (owned by su) insert into p values (5), (15); -- all these are as expected: select * from p; -- returns 5 & 15 insert into p1 values(16); -- permission denied select * from p1; -- permission denied =20 -- the following commands seem inconsistent to me: vacuum p; -- skips p1 with warning analyze p; -- skips p1 with warning cluster p using p_idx; -- silently skips p1 reindex table p; -- reindexes p0 and p1 (owned by su) -- RLS is also bypassed \c - su grant select, insert on p1 to foo; alter table p1 enable row level security; create policy odd on p1 using (i % 2 =3D 1) with check (i % 2 =3D 1); \c - foo insert into p1 values (16); -- RLS error insert into p values (16); -- succeeds select * from p1; -- returns only 15 select * from p; -- returns 5, 15, 16 =20 The proposal to skip privilege checks for partitions would be consistent with INSERT, SELECT, REINDEX that flow through to the underlying partitions regardless of permissions/ownership (and even RLS). It would be very minor behavior change on 15 for this weird case of superuser-owned partitions, but I doubt anyone would be relying on that. +1. I do have some lingering doubts about whether we should even allow inconsistent ownership/permissions. But I don't think we need to settle that question now. --=20 Jeff Davis PostgreSQL Contributor Team - AWS