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 1utLaM-005LYt-Ka for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 07:37:48 +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 1utLaL-002Ysf-SO for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 07:37:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utLaL-002YsF-H1 for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 07:37:46 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utLaI-0008YP-1J for pgsql-hackers@postgresql.org; Tue, 02 Sep 2025 07:37:45 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-55f6017004dso4528254e87.0 for ; Tue, 02 Sep 2025 00:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeltef.nl; s=google; t=1756798662; x=1757403462; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=clB1TmbtavqyLtgcYmhF2i0ZKSF5sKFzRzQwq9Gn+C8=; b=UPhdUsM7Remt0h24PG/1JVb8jzk5q61+FSbyFUp7YDJqHGRlAUqXtOUOabztsOKaw7 7/ZbaLEAcjA1/Rq226r7MA0pXO123U4BzR6dAEhbJrT9OEQrBAZLEBZyFJPRhPySU/ws 86rZXrzHEaQHQJQAKqtbp0p0DFWO3Ph2XjktXTfGW79oWvHzWlo/1d9bQKhkWZpSiWlN /XmUpOqIb9vbhlyGBVYq4GfsJ2zv8m9IQ19ESIRRq1MzjJHOrK2Ragf34vRYSonDReFn Ssi4p4trGB3PdD5cRlMiwYuxfo4J9OEY5ni7Gx9gvVozMW2kWg8nxaMzTZYHq82HQ7vK af0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756798662; x=1757403462; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=clB1TmbtavqyLtgcYmhF2i0ZKSF5sKFzRzQwq9Gn+C8=; b=Brq0kWdHZsnf7392sE0mrGwB/r9JGj1vP7h2p5K40M5ypCIb6vRKz7bAxZvErwaI3h 1OqqyZSpZz06lgzHp+dxBpsLEIoxBOCBvVpLirbW5IeNwgMJtRVQHqoWeKOxsOleC0Tx A11R1PZXV7h75XfyVmXtFAcOvJmR+pLAnN/uGIlQds0B9P5vGH68/yMERoL8IW8ZD4vq 02DE+FSKBv0eeG0GEQDSpObZr1VXV33OSjovzgp6Xfy+PiWawDhANCS6wGnNy79M+5kw Hpkqu4QI7V5kogpl59SrQwkgaxywMT42Wo+uDdZXvZSIQWvVjPOUZro18q6t5YKze4Mu wbzg== X-Forwarded-Encrypted: i=1; AJvYcCV5RbzBMB6lTI8WkzTgM6qvKgc5Vx51s7iKXejjwM2NkkKXeqDqYBp9dmb+kaY54lYz8Qx6yCeBVswQB298@postgresql.org X-Gm-Message-State: AOJu0YwH2ULTN4mbx5bddEU+zilBXAw3Dix7exRTf4YE+VPbyvC151bS nv8ppFHwomv92O1U0YKesd98t4HNgNC8PIn6XFAoJpJMBOXmTYm0rxYVzCYif/Q4+0XK+wfHlJn iU6yMdCHJbzwTC2+rQ6Uv3p81oOinUTAzJVnseNtilA== X-Gm-Gg: ASbGncsiMbIoV4PslhjL4UMVFAcCw1yByVdfmT/aPFTaxSFzGI/h7VJdS9ojoCK2QCD 3QKFeHy5nnwofqSWKpmsbBbgqezF+a3ttsq+Wx+EdIZ7mAwXLGraUrJiKBHShvtbglQMTdyXq3s 0RbTf4d74cc5DoYeAtjWql4/mY+TtO+gaf1hvYEl9FijPkq5BRAMoGxARUTqUjQ4R+S29El2OiY /GviY/v X-Google-Smtp-Source: AGHT+IGAFcyj/q9793IzU178ObHPGzjZ+i4gn9VXfFP2OKxuSzNgxSSi9G9jvmBjGBe555Zu+YxDyd4zttWqxCLzrNQ= X-Received: by 2002:a05:6512:230b:b0:55f:6a6a:4956 with SMTP id 2adb3069b0e04-55f708b16bamr2379199e87.13.1756798662355; Tue, 02 Sep 2025 00:37:42 -0700 (PDT) MIME-Version: 1.0 References: <585e996c-a5c6-4e61-acc4-d92b7a1458ea@vondra.me> In-Reply-To: From: Jelte Fennema-Nio Date: Tue, 2 Sep 2025 09:37:31 +0200 X-Gm-Features: Ac12FXz2XNDj-jtRGIAK4mZ8EzTqMv0QXNti7h2ghbcsSkd5iK7dozqCTKHwoZY Message-ID: Subject: Re: Extension security improvement: Add support for extensions with an owned schema To: Julien Rouhaud Cc: Robert Haas , Artem Gavrilov , Tomas Vondra , "David G. Johnston" , Jeff Davis , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2 Sept 2025 at 02:03, Julien Rouhaud wrote: > One not too uncommon scenario is an extension in a dedicated schema that creates additional objects dynamically, for instance creating new partitions using triggers on one of the extension table. Interesting. I didn't know there were extensions that did that. That definitely doesn't seem like a very common pattern though. But I don't think that's a problem for this idea. In the implementation I'm working on, superuser would still be allowed to create objects in such locked down owned schemas. So as long as the extension upgrades its permissions to superuser during these DDLs it should still be fine. (easy to do with SECURITY DEFINER or by temporarily changing permissions from C)