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 1rSe0S-00Ezw1-TW for pgsql-admin@arkaria.postgresql.org; Wed, 24 Jan 2024 14:13:33 +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 1rSe0R-005F7b-UX for pgsql-admin@arkaria.postgresql.org; Wed, 24 Jan 2024 14:13:31 +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 1rSe0R-005F7S-DW for pgsql-admin@lists.postgresql.org; Wed, 24 Jan 2024 14:13:31 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rSe0O-003Tzl-CJ for pgsql-admin@postgresql.org; Wed, 24 Jan 2024 14:13:30 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-55cca88b6a5so506903a12.1 for ; Wed, 24 Jan 2024 06:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1706105606; x=1706710406; darn=postgresql.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=qNqoQtGOGgGZI6HGI6I1lZzIBt9ASMuU6/yaZBJNUVY=; b=PuMr+2onDd9uTgnHsHkI7ODUabnoe+9Ts08u1QcRY4iLzWtqzN3vcyR3YmohS91TEk 5oXLfZsbgtcbnFn/HVDSh6sr4bh7bopXXuYi5dDUIhjGHKs8HQE+OR+ykW8+cWwP0XIw txzV2x2Yjw+0uh+Qwb2Lj6Iy7hunb8MVoloJFQY+ad+y3BFHd/G8pex0XR1BC56ubtPo SVRdp97r0hxnG7/3dL6WGxMRmp80CSJjjhDSvMMqTtdxg0S/EJXL1rejXxeln9ZgJ7RC ylotXR/9M0cVC8w4b4Pu0wQhHQAQ5bn7uJREUvGrIQvG6C0Tm4oqaxbFFSX4x0nv3nGd KLFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706105606; x=1706710406; h=mime-version:user-agent:content-transfer-encoding:autocrypt :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=qNqoQtGOGgGZI6HGI6I1lZzIBt9ASMuU6/yaZBJNUVY=; b=o4+cvadJa1v0aHVchVriu7XAXMi0EIVyowcOlEH8ZbwcagKP/W3JMPBnGW9aVhoNAO V4DSXBJo8QwA7ZWO7zC6K5si15iGfhLaLsjbAjah/lD2GIj0KQmWtUoUUf4tOO8TgWD9 IaTSACZmewdc/hBavDlSuO7yJJnJeDCgrmko7lxENSNBnLwAOYtnAQPXusCKnc9K11Lf i5UXIw9s8O2nHYx2SiV3w+93yI5sonNiSqXh/e8wxAaUpSwtb2rI4mBLkGBxRlVaX8ur JEDtWqoU3tv/GAvpi7SSUn6xyWG+luXTCwE23sGto6G/VnTwhf7whwiREkRYFBXRyMSk Z76Q== X-Gm-Message-State: AOJu0YxoPDKHNdAtbRIzeUaL/Y0nFiC4YMwfBb7fFlrD/e7FDlg9PKfI H20QDcm9p9u4ExdRYsLpzmntPqabEz3rCEvJdJLCAVMqNIkj7VR95EGvuYYWe6E= X-Google-Smtp-Source: AGHT+IFPm1Y6Xo8XNn0HlqZX/HGNOjCFiYyVVz2nEQ+mFI3qk4+s8gAYQPK6FlHWvD04zYbmijYNJg== X-Received: by 2002:a17:907:29c4:b0:a2c:e323:b71 with SMTP id ev4-20020a17090729c400b00a2ce3230b71mr672840ejc.0.1706105605914; Wed, 24 Jan 2024 06:13:25 -0800 (PST) Received: from localhost.localdomain ([2001:871:5e:6c84:1134:d324:af03:8ad6]) by smtp.gmail.com with ESMTPSA id lt18-20020a170906fa9200b00a2ac199ff67sm15640335ejb.170.2024.01.24.06.13.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jan 2024 06:13:25 -0800 (PST) Message-ID: <3419e4a28e16f2155fd97fe666b1a931ba7067a9.camel@cybertec.at> Subject: Re: pg_dumpall and owner of the extension From: Laurenz Albe To: kaido vaikla Cc: pgsql-admin@postgresql.org Date: Wed, 24 Jan 2024 15:13:24 +0100 In-Reply-To: References: <17144af8b80466cf6c807d531de8410f1783ed90.camel@cybertec.at> Autocrypt: addr=laurenz.albe@cybertec.at; prefer-encrypt=mutual; keydata=mQINBGGDwAQBEADgbWy5cKXQld3N2mF+DFyiNFbi2oBl2T+XgxpPF8wTRw2D/u4bBKXP0SYSE/lA86jIVNWWU0gf1KODIkVvgJm2w4vH2VBV1b7ddVViGl1Iu+9zaRnv9wulhnH42KefepXnoean6UT1EzLM0opF/Ik0j+40TxdRtobkBprkQUyHDXWlHc2ffPs3SipyFEP9AVLf7ejRC46CXWDnsqjOBSMEW8Z4HiK/8RrPZBsKLts8dJxKF4pygOdJb0CWk8k/X1jbcfdxo+zOLjOMvJcSJ2pFdJmQHU+JufB3rePziqQ2S9Ur6sccr9XnTC1GVBWN4Lf5VHq+vf+bFJjVwg+2hrySZnAVfcOrxoqFLErr7ug1zN2nM1kcpgA4VWn4gxlJtYNYYq+9WxX5dtvnNANlG3ZCrRKQzl8lxtzoF6Zo7LUhEqPaHDwn7Rvs+IdbOn41lF5UDTJGqmC4gS/bZydW2Fy3YWm4aSaN9fgFf8D+PVkrlKAZB7gBLz1TyHjbcRf85cYF+GKKrDld5SzMB/V60VX3oP/Eo8ikFpyWaqiz1f9X7MBot3/PjJkY+wDzp3nmb19QEcOBuQiSQ4xds2r0HewbuHTAR68u8jNNMGmpm2j4x+g09Jd/WQDjqlTBZ/jEltH41fYCCPWMfljXTOOXu2eLNGdfi7ETZogtwjM9oTtSPQARAQABtCdMYXVyZW56IEFsYmUgPGxhdXJlbnouYWxiZUBjeWJlcnRlYy5hdD6JAk4EEwEIADgWIQR0CqhbZGGABqoaSbdi8bhXA2EdmAUCYYPABAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRBi8bhXA2EdmM/6EADK232JCwmBzhlj8h7U9CjG6kx0JHP3uJGv+XfsHtHAlmY/RCwF1BHMEsRlk bT5UrLvJ2jb99bA9QARzhFaxzyn0F/BUKzuIjRGNs/n6d5dNUFA0kOt8sX+TacmC GEyjEBCrVCm4ranBiUyePn9NhHNWnaex7pJyqvMLLdwW9BEMJx0Fqo+DN8ukbXmYRsmhEtd3ue+x/luYmOmJnaGtzInaY5aOJYbW9XqoRIZkZvOCgbi1FfvNmoqWa+3oVxTOgw9RafjJDyW0lTHzKGjbGI5ofMU98l+/hKJFYJqWUF6VpFJY5YIcN/1lf4ZICMwDl+MPIVo/tpq8L10seJL28nLlvw3K+cI+TVW8IW/qL/LyVoDofI3USeOORuYmhpWRhik8JXX6xf3v6GrRilJIPWNFIJbxm1ZblQiQnOw3IOW7T+8nAmPin1HKqM3VrOrJQ2VtShsefNBibNAsr1oFaqcDBkn3yGG8i6CTW+FyO4PZ+/EwNxMVgktxbYdy5AT1/lpXr5tB+phhLIyVfiBvrWs5EThxYMQ/L8Y85c3GMsAy1l/x4h3jqySIYy3SCU9+jc5UVuNnXljbvkEzJ+NLWJ6C1rACFWrMszgPdh5tCrlRY9PpmYll4JbCgb8BtxEIUmR+xr50/ZElEK5iml7Q00KUekCcDt+36PsyGFTXBzNOrkCDQRhg8AEARAAzOZ2tLHlI4rrhG411h6cdCFjBZxuljaFCxFyHn3m6wbGLqwBUWC5k8UrRqjHMz88KcTSaNO7XGAmCqPdWd2SeflPZRnNTbjsVpw7mLdffsBm4JX7kki2Pvk5h0NtYeidXT1PSpc2ri4DutYXuT9uD8RAm1wUDCE5HQNUihT/WH6opt+hskHW21uHao0+y822tG0QQcGMqdQR5Vxdxj89wiEPdqW+HpU/oOZIhrf2E7prduAppxixjHy/o1rcnoznnJvc8D3+YgI9O0LrBMij89dM55pRGbLovTR1oGR3U74sX774+0xmSzeIKwZfiMUz7Atlvfk5SHOsRUFPN2Ux9kaXiiBibQpHFxt7b lDrT4wxdLJ/XCdbPPAyl+lZtOLsaHEEZvYNyTXwZc35dVf3R4/oz20HoG6s7ct8e1 AQygj43XAERzty9SkWgxs8+grp1PrGx6FHVSYRqBM8dS/ZR6yRVwOwJXPyaSSqfIF21DkE4j1y4n+ItSewPGoRp8K/yWCikt6qlkVkO2ASNIiX04fAbtzwVOaNn8ZMRNqyvLc1fED4sr49onE4cAIcBLjcC3KL+w9DUGRQCdziROj5H2Yl/sXGPdMciUHo/Uz2rggc+2th3bQiMhrHWSsBpUkDQp0yWewemstPpPgBL3h2fHKaX8B9oH5Qu/H1IgrOuX8AEQEAAYkCNgQYAQgAIBYhBHQKqFtkYYAGqhpJt2LxuFcDYR2YBQJhg8AEAhsMAAoJEGLxuFcDYR2YuPwQAMkpGtR80pQ1gVsONhdkqj0H2eU66efP/gO3CoyaoIcvrpKYj7C2HipVSmkt1gpByL0X4AMQ/vKuknUz3wd28Ba+G1dCfbVs/Xiusq+SmpUj5rTwmYqdSjWMuCo1R6oS5hdJMdUUJYGMT0QkVlm1KnW8jkmCTl9GzjDxOAsN9O6/6lPzaGFtk9XF+34Bry/N4HKiJkqpC4+UTd0AprPfzJ2jdT64e1F0+W88X8y1bTTgNrHwK4mDiLnlE4SKRuEm54lNhJz//ar86Or5BErzNpM6TL7lk44QS06hwsMrEdKIy8J/SYJPjfzR8tIUnKscclVpOgjKaBqC+0iFiVaRqAgfOlIEiezX6kMh5Q2FIUfqs46qWhhXjRrdKOEoStYAaikdLu5ZXr7vfb0ZaDh+ZwTQtbSMFolyOkecwI81MCdbMfT/1TqIGTOdAj5as9fAakk0jb2pXgUYQ8X1DVTR8ahSDVEaw9VTmWiSvTxvguVJ1Mb7gG4Gmh6aviDTJhfXtH4rPUNXhDLqrTH8JkJjyKROOMakIF68Hjse5vUfUxreBEOtb5r1Coa2Fe7ncJayaSE7ryrDbFqpZ 36UMAx4ulWMyqJajLNGY0DdG8qIsR5nxRhrnK/mrCidZ8F9/D3bWAl4rjtHlsztN59 +AnW5l0HsQcY9ntFL/zEBOaonjdJf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2024-01-23 at 18:01 +0200, kaido vaikla wrote: > Yes, i have a real problem. To keep things clear in database, my design i= s: > - every application has own schema > - every schema has owner who is not a user postgres > - only schema owner can do DDL's on schema >=20 > So if some application needs some extensions, then i give temporary suppe= rsuser privilege to schema owner,=C2=A0 > if "create extension" =C2=A0needs it, extensions are installed "with sche= ma" =C2=A0And revoke suppersuser privilege after extension inatall.=C2=A0 > I'm not sure, is it my design against postgres concept or not :(. >=20 > But in same time, i expect that pg_dumpall will not change ownership or a= t least gives some error or something. I think your expectation is founded, and the current behavior is surprising= . At first, I thought that would be a security problem in combination with trusted extensions, but then the objects from a trusted extension always belong to the bootstrap superuser. So, all extension objects always belong to a superuser, and a change in ownership to a different after a restore won't be a privilege escalation. In practice, it doesn't matter much to which superuser extension objects belong. Your usage pattern sort of breaks that. I think that your practice of temporarily elevating the prospective extension owner to superuser is a questionable one. You end up having extension objects owned by a non-superuser. That probably won't make much difference in most cases, but it could matter for SECURITY DEFINER functions or views that use restricted objects. And if the extension object owner changes after a restore, the behavior could change. I don't really see what you are expecting to gain from your design. Instead of temporarily elevating the schema owner's privileges, why don't you create the extension as superuser right away? (As an aside: you need a superuser to turn sumebody into a superuser. Don't tell me that your application is connecting as superuser...) So while I think that the current behavior is less than ideal, I don't see it as a massive problem that needs to be fixed. What is it that stops working for you after the restore? Perhaps some documentation for the surprising behavior might be in place. Yours, Laurenz Albe