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 1u58zX-00Cvz1-UK for pgsql-general@arkaria.postgresql.org; Wed, 16 Apr 2025 20:04: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 1u58zV-004gsP-W2 for pgsql-general@arkaria.postgresql.org; Wed, 16 Apr 2025 20:04:14 +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 1u58zV-004gsG-K8 for pgsql-general@lists.postgresql.org; Wed, 16 Apr 2025 20:04:14 +0000 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u58zT-000RsG-1a for pgsql-general@lists.postgresql.org; Wed, 16 Apr 2025 20:04:14 +0000 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5f3f04b5dbcso77401a12.1 for ; Wed, 16 Apr 2025 13:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec.at; s=google; t=1744833851; x=1745438651; darn=lists.postgresql.org; 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=0tu/EHKqSrDyMAf4hCSz3MTGifULQTOSnXHHsefqbsc=; b=oGBAc60gARqDwpfFefMjFrZbYJDz8IIvR8BXVsTj6p0WDgZGGzlfsx+iAX5EECm1y5 VCJ+rwMWewuaxJqgEz5vwkIYN0ztcIulM5kkGzW65xo6T1LdCBlvdRJUD2g/bQ0GQbOP qu+h5L6JFixeoLjt7fdT5lp+sR1ubKVygqTadei+wZ+q+nzw+74SRhbPE9aPlrFZkH5j FrOgDH+3V1lLlzSulf7crpDnXAqR1PUBljfEo6CT50Bd4f/Io0Jrlw3z4rSMLOjXBVw6 odBsvAebCYApURY4qzCVLKCvpTJaRDxMnPI2J5RiSQagL2++djsXzbEVx+saDceQYUC1 QBXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744833851; x=1745438651; 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=0tu/EHKqSrDyMAf4hCSz3MTGifULQTOSnXHHsefqbsc=; b=kVFiiimY1lfImX2d9JhevrjieE5sLotWJ8O4068RW3Cau9An1nQkadVGhgkIsCZkfs rsJGlt1/Cq5dFrp3DWcpzMHyhcCAfq3mFUmEijzo12m5r3tOd1lVrtnAAYVqQYX1xWt+ D4/UL1ymrNnGPkMRiPQ3jvzJD72oZAvkKHHDU5OzBKfAh87ycsG4pOEl4Nh+6lPffYeV 8JKALC++VYNINJxb9Dk2m2Mo3hzpdACL3zaW79JMUVxngHs1JCJY/1Ur8WezFKfD6f3e gu5S64i8oNhw7LPfZ9VN1WVj4d9N2SWZOHYbxMs/44gxdTq043j/CguqzOsq3RvO0KKn 8sFA== X-Forwarded-Encrypted: i=1; AJvYcCVSVbKAYYPRJlLUkZccwlFEFOMfm6WsFjfddAt9cVHdKTQDm74aVs6ehdVkT4JurqDp4JSa8eCsqBG7vIBv@lists.postgresql.org X-Gm-Message-State: AOJu0YxWtqNkS++facs0E74O7j4gwW7a6BFYWBjJUCEWsX7doSpzKKMK PxUf4Lr+ruylEboBguKv5bCNsR3nuOJthnPWRYJ5yZ8op6c4u4ZNpQW2SPgeW4U= X-Gm-Gg: ASbGnctF6+icFqxRgXkCXWl1tENmBbpGylpc92mOfozqKDWjkazd3sgou/FYBLyIuuS J997dzTw5qnHe+xvBx/TxHin92g9ne8moEp931ugMg1sVTjDqCcfZ7X4V0pa668lfhs40r7YeNO G0xZiDNojSuP8X9ChRdDEeuZy4KPcmAgWFu/MN0Cr619ub6ZRf+BQCb/afnBVwRzdDqsJKXVGOJ 8HFDMSpZDNsIrM84Ff+ZioTt+xFyjFKDHZrsNNCKKz65JVOB6bE03tvpb3G5C8dsvIk0kkPVU22 /w/67voKAef5O6kN7NZSridfi7bo2VAiXH52dWD2WCoe6iSBVLocVDJ8wnAe4g== X-Google-Smtp-Source: AGHT+IFMFylRAEmGS6iWy9QFz7C3KZUkjhurDDhosZnAVvuGVwbT3k5nJpR/03MIk69igbTi2ECidw== X-Received: by 2002:a05:6402:42c5:b0:5f4:b0ab:9df4 with SMTP id 4fb4d7f45d1cf-5f4b74ad8f3mr2587912a12.19.1744833851373; Wed, 16 Apr 2025 13:04:11 -0700 (PDT) Received: from localhost.localdomain ([2001:871:255:52d3:3ac8:61ab:b634:342]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5f36ee5500dsm8850625a12.4.2025.04.16.13.04.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Apr 2025 13:04:11 -0700 (PDT) Message-ID: Subject: Re: Fwd: Identify system databases From: Laurenz Albe To: Dominique Devienne , Tom Lane Cc: Adrian Klaver , "David G. Johnston" , Igor Korot , "pgsql-generallists.postgresql.org" Date: Wed, 16 Apr 2025 22:04:10 +0200 In-Reply-To: References: <817abeac-d628-4279-bfef-9e1e3aa1884b@aklaver.com> <25b6cd49-f871-47fe-bf3b-5416637736ca@aklaver.com> <2dffe860b085b927726a052bcfe16ede704ab923.camel@cybertec.at> <1898934.1744814354@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 2025-04-16 at 17:06 +0200, Dominique Devienne wrote: > So in a way, you guys are saying one should never REVOKE CONNECT ON > DATABASE FROM PUBLIC? No, not at all. > All my DBs are not PUBLIC-accessible. > And inside my DBs, I try to revoke everything from PUBLIC > (USAGE ON TYPES, EXECUTE ON ROUTINES). > Nor do I use the public schema. > And I never use the "built-in" postgres database. > Basically I want all GRANTs to be explicit. >=20 > Given the above, I'd want to not provide access to the postgres DB too. > Yet have a way to discover which DBs I can connect to, from the "cluster = only". > Naively. >=20 > Sounds like you are saying use the "postgres" DB for that, and move on. It is just fine to restrict access to databases as much as you want. You just need access to a database if you want to run SQL statements, be that SELECT or CREATE DATABASE. It's as simple as that. Restricting access is not wrong per se, but if you randomly restrict access to everything, that's not so much a security measure as a way to make the database unusable. I see no value in restricting USAGE on the data type "text" or EXECUTE on the function "upper()". Modifying system objects is not recommended and can lead to trouble. Yours, Laurenz Albe