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 1nUs4P-0005Kx-CI for pgsql-admin@arkaria.postgresql.org; Thu, 17 Mar 2022 15:29:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nUs4M-0001oO-BP for pgsql-admin@arkaria.postgresql.org; Thu, 17 Mar 2022 15:29:42 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nUs4M-0001oF-15 for pgsql-admin@lists.postgresql.org; Thu, 17 Mar 2022 15:29:42 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nUs4J-0002M9-GG for pgsql-admin@postgresql.org; Thu, 17 Mar 2022 15:29:41 +0000 Received: by mail-ed1-x52b.google.com with SMTP id h13so7030794ede.5 for ; Thu, 17 Mar 2022 08:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=wPVWPsxY+oC/LO38E9x3q4pS40526JexsS6RTCk0T5o=; b=NL/7VAT8kZPe8HTwqDuoID5S1f3ut9GGIQDQXMrKjyiJjUm4rN7pWMD9J14ykXbPhN cSd8oUGJp/wUcQAjQ2F25hoFCRFVtg76tgccUp4aYH+fYG+kon1bebqy56BvwTpqLOqi ZhpeofELNWmlPTJMBRF+3UV/T1icU5vvoVfQUFxbZ6Vfj8BYP3Qb/K2ed6o+6Z7uC+0+ H4BNx6mYHAh/10l3hhQ15LjdgpYYcfWN5rA0wCDw8pUBtvws3hSwhWa9sic5YQ52Dn3e Eshbrn7PMO0byMAFeQ4ZiJmD/oN0J3xVK/l2AuSjWJjxlMv9bK0LfqU7S80NHtdGCblL TzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=wPVWPsxY+oC/LO38E9x3q4pS40526JexsS6RTCk0T5o=; b=bOdRGKbrgbDhHa7yq7Ld+QlZGRg2RkxyZFve4NwD7GyIRUFcVwrIRswfBW6aZagTYK AMDlVPMTHyCeQc5FUBpCRbi66e60cumkONvdSiom8i6D2qXAcPz1nZQgtdlemb2652f9 zjZfoHwL4WIggwTu0CYIXo7c8nSLq3VevbCjXCG1GZJ+9vf9UhnqUFoD+la7+eLuWW3r F0I21lJo5LWGUqwmrIMer+sVLLKEXeFK0RpH6sCBRvgki8tlEQIDejrBdtpVgw93VIvZ jDI/PHLHvpYhksbzkL5UJfq/EyUjEvYRUGdvT/Q1HbTKbe7TNYaRiXZRNsmSuSX/PmHk t87g== X-Gm-Message-State: AOAM533D2V/tlWaD84u2bAlcRRcQHywx6CMh5dEANtXRD4N1K/lgeeor JLixTLa3cEvosiWoF+ub5kdTIYxZWvbPyg== X-Google-Smtp-Source: ABdhPJzVyLA3TtyEc1N85jcYrtQzRjxImFF1k34oi40ba6Axdzk+xwyMpc3jmONj65SCc6Cu9uPTZw== X-Received: by 2002:a05:6402:5303:b0:416:13c0:3e75 with SMTP id eo3-20020a056402530300b0041613c03e75mr4993815edb.299.1647530976043; Thu, 17 Mar 2022 08:29:36 -0700 (PDT) Received: from localhost.localdomain ([2001:871:5e:1baf:527e:4d24:76aa:18b2]) by smtp.gmail.com with ESMTPSA id sh31-20020a1709076e9f00b006df6faf3500sm2555621ejc.51.2022.03.17.08.29.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 08:29:35 -0700 (PDT) Message-ID: Subject: Re: Shared postgres-cluster / permissions From: Laurenz Albe To: Christian Lehmann , pgsql-admin@postgresql.org Date: Thu, 17 Mar 2022 16:29:34 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-3.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 2022-03-17 at 11:48 +0100, Christian Lehmann wrote: > There is a "alter default privileges in schema public" in place which grants ALL > to the rw-role for new tables and select to the ro-role. but it only does it, if > the rw-role is creating the table. if the user (for example serviceuser) is creating > new items, it does not add this default privs. (which is by design, but bad because > other users won't be able to access the table). > > do you have a good way to work around this? is my role-setup "correct" or do you > have a better idea how to do this? as i understood, there is no possibility to have > a wildcard-default-privilege-setting, right? You can run an ALTER DEFAULT PRIVILEGES for each user. But often it is better to have only one role own the tables. If all roles that may create tables are members of the rw-role, you can give CREATE on the schema only to that role, and anybody who wants to create an object has to SET ROLE "rw-role". Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com