Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uugdD-00FO7u-2A for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Sep 2025 00:18:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uugcD-00BEq0-1S for pgsql-hackers@arkaria.postgresql.org; Sat, 06 Sep 2025 00:17:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uugcC-00BEps-Na for pgsql-hackers@lists.postgresql.org; Sat, 06 Sep 2025 00:17:13 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uugcA-000l92-2j for pgsql-hackers@postgresql.org; Sat, 06 Sep 2025 00:17:11 +0000 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-76e6cbb991aso2294876b3a.1 for ; Fri, 05 Sep 2025 17:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757117829; x=1757722629; darn=postgresql.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=nRsyFa9qHN9om6KhvoA/0dTJbN9/otMlYc5/jjhu2/8=; b=hNtKqzXVtukLG3cDmLwOVgLEdIusmvcp4zC1Yo4fPPAGjGMO65PhZY/aQCBOo8qM5w oDswDPBa0919P3uN12BRdxbAyfdrt+7aLZD4Fzrb0cWTk3f5Utf+cIWoq7Maw2GqmSFF NgVnaiDm8X76X7KSaPT6kPmyOS4X7wWLmiX6shd7IutkYX7XmRaGMe19VvfAXNMrLy5I hINZlxn2971+hX7X0NxXsDNB216mk4gHS97Geqs4oxZTdCO0Ps9Q6hw3ezSzm+KpuBtz 0st+PIjD0tDm/wKZi27tuxe/cFo89MKFyxGNfguLWfxTeG7R95AhqK/0QfId6ul7NlCB Cq1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757117829; x=1757722629; h=in-reply-to:content-transfer-encoding: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=nRsyFa9qHN9om6KhvoA/0dTJbN9/otMlYc5/jjhu2/8=; b=UOKidzZElDX0IVGBzP8w5MJ3mdI8nwq69jMwupuZHenUZsc6NJeBtf3/4sPOXv07CW Fz1BOgHOFMDqP4Qiwhbx/Hd1acd0l7jItUooA+kft9vDR4vO/wueslRf5TFGdSS+pP4b C2g4k4bZSSdWY8WpnnNyi6VKZiGHSmTOv2+vOFry6xQ1y5nu+bo1Y0O7vsM3+8OKkWd3 kiomp+XtJwQgKtms8Rnb2Uut9txu9dJXWoeFBFAm4WUM82Od8o2B/YT5pqyRPClf/qOc hR9NOF1RdmFPEmdu0NQwlVnCqeGmP0MYOyEg5Ij6S/p2CCsuWWaS+VTOXQl7VcxjQkr3 XOkQ== X-Forwarded-Encrypted: i=1; AJvYcCVj83fywuLxOHfxLr+bPDc3TnXSL6U8++Sk1y1ifX7/J1Nua2qTX+XqsNn7Fqenk3qKRxVwy8mgKT/hLbqT@postgresql.org X-Gm-Message-State: AOJu0Yws4rhvhxn28pEckX3c+Gn/D7TlZY3RDiEBXKojvApK6Hbx5tfq AhdNIzh0CPnfyGYse86gmu1XeyVFyKxV63K7OUxEV7heEfkMT7C9i7NJ X-Gm-Gg: ASbGncvWVS3oJeXII5FR/NTUbCter2R3DxPWeWI4VZ6kNMBs/FzlyCT+KvvTihQYfLQ NOv2tPPrTJpnDNarzWvPWnlhqBjgmTATERkA8j+VSuZa/Fx3v4Zzq43RprFyD1goaDqD6o0Wwr/ q4waiLY+RrP/b4YaO7/zoAZNmdCp7bAmJQnNS+Gdi4D1I5cyXHf+lpwdxrHsaF3f2RWOrqsp9Ap yIudSjBzRx9KyURbsK5YjFULP7obCfwPfzA7nHFVbblvvomjtNx7MxNn6XDxxNXZ+DhCXSmCtkR m1fqxKwA3qewdiifLycM9ZLOm+eS0hyHUsuqquWL7SXSlLKqQ0BpwFp13JIzw90qwalLPRkY4MY NUcWb4xCeFz9Hljk= X-Google-Smtp-Source: AGHT+IEb9UuETBw9vY+kN6csR27JdCIHHlaYGmwilUmt7hoMDt3A83NuNLqFNsOO9DU2eyXVKUoAuA== X-Received: by 2002:a05:6a20:9191:b0:24c:f15b:9855 with SMTP id adf61e73a8af0-2533e853366mr991328637.21.1757117829060; Fri, 05 Sep 2025 17:17:09 -0700 (PDT) Received: from jrouhaud ([115.43.41.38]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7734d48bb78sm4464331b3a.87.2025.09.05.17.17.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Sep 2025 17:17:08 -0700 (PDT) Date: Sat, 6 Sep 2025 08:17:03 +0800 From: Julien Rouhaud To: Robert Haas Cc: Jelte Fennema-Nio , Artem Gavrilov , Tomas Vondra , "David G. Johnston" , Jeff Davis , PostgreSQL-development Subject: Re: Extension security improvement: Add support for extensions with an owned schema Message-ID: References: <585e996c-a5c6-4e61-acc4-d92b7a1458ea@vondra.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Tue, Sep 02, 2025 at 09:35:45AM -0400, Robert Haas wrote: > On Tue, Sep 2, 2025 at 5:02 AM Julien Rouhaud wrote: > > Requiring superuser permission seems like a big penalty, especially since the > > last few years have been all about *not* requiring superuser privileges. Note > > also that not all extensions embeds compiled code, some are just doing plain > > plpgsql and work just fine. > > > > Why not requiring schema owner privileges? > > I agree with you that requiring superuser privileges is undesirable. > However, requiring schema owner privileges isn't really requiring > anything above and beyond what the permissions system would require > anyway, since at the start, nobody else will have privileges on that > schema. And that's where what Jelte was proposing -- and also what you > propose here -- seems very accident-prone to me. It would be quite > easy for the user who created the extension, and who therefore also > owns the schema IIUC, to accidentally put other stuff there, or allow > others to do so Requiring schema owner privilege wouldn't allow the user who created the extension to allow other users to mess up with the extension's private schema? At least not with a simple GRANT on the schema. I'm also wondering how much you can prevent the owner from doing changes in the owned schema without leading to unhelpful behavior. Would the owner still be allowed to create extra indexes on extension owned table for instance, change the TOAST setting, move them to other tablespace or ...? > The first thought that popped into my head was that maybe your > extension should make the objects it creates part of the extension, > but I think that doesn't actually work, because it would mean that > they would not be dumped. Arguably there is pg_extension_config_dump() for that, assuming that this would become allowed in scenario like the one I described (and modified to also emit the DDL in such case). But it would be hard for extension authors to use as you would have to call it only with some major versions. We could do it automatically, but extensions may not need to dump all tables and/or all rows. For instance in powa we have some unlogged tables that are use transiently during a snapshot, and those tables shouldn't be dumped. Right now if such tables are created by the extension they're always dumped, but it would be good to make it configurable if dynamically created tables become part of the extension, one way or another.