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 1nHP9z-0003Oq-8V for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Feb 2022 11:59:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nHP9x-0002o1-Ic for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Feb 2022 11:59:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHP9w-0002na-Ri for pgsql-hackers@lists.postgresql.org; Tue, 08 Feb 2022 11:59:49 +0000 Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nHP9s-0004oH-4e for pgsql-hackers@postgresql.org; Tue, 08 Feb 2022 11:59:47 +0000 Received: by mail-vs1-xe33.google.com with SMTP id t20so3074190vsq.12 for ; Tue, 08 Feb 2022 03:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joeconway.com; s=google; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=hGjEA+C7JXwbSI74fv/xgCMITQ9GJFB75EQEVMi6eTg=; b=arUSy65XA5RqYAN2Q24Zthhrpuq4N/zZZU28g70oXU77J+ZlZSZipwXwmDHkTqZG7/ 1ZK/2l4mazS9oAzMo6jN+WlRb3QvcRdp2RP+MRFcbD48t+4euyqYRQY2PpaMKUEXpZS5 74oRiQvxtQKEhOjCEQU5e6/dVOSfzPNNvtujeYWoh5DzuNtWTwlGhelme4Iyf6W+XM1M Ohj2485WO2a8ezSsr7naeSUXeZAfll1hMycyKdbLGbpmSCS2WYt3ZeGUmdkqxQHEsh41 hOL4BgMjYIAjHcijZw/1crbmkoV/Bdbe1RibbYPoxDFFli1u15lxywTmeO6uvW4WpTRk VLDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=hGjEA+C7JXwbSI74fv/xgCMITQ9GJFB75EQEVMi6eTg=; b=sjD9IGErDb8OtbwViDBLsozFDqywkcJrkUhPmHPzxZLyLwwWUCgcEbUK1U1zTFRqg9 D/65iNFtLB5Nu2/Bxvuo3sSxvnnsnv2ojmPA5X9M3OVLNDegYWmSKzsV4z+/OPDgjtQS dq2Y5bIyzRgKv62RylwLw0VS9YfYPbt7USc7uDpEQfCsvsfKmwjTsqtUyDBQp7B98WAy ohF+K4dXbh42zzhdRsBywmN4NrS1mG3BZjmUas4UaJBF126Gy+KUbqprcNP0kuaKXGdE TtZMJL1QJgl/QzrEY9nzNRNUM6fAAbPTRKD/Lmasy8ppnoD2WGetqb28K5oZp6gZCeLu 3aZQ== X-Gm-Message-State: AOAM532ZV2geSB+BABDn8uM+FEJBOY3SQalkSmSagrbiUrf+CzKBcRCX IAjbhD390FCILfTd1FJJYKqeEQ== X-Google-Smtp-Source: ABdhPJzaMTBvwYEWfssa0yu3cLI2z1HAzTSM47SfxX+ldM9bDPAQ2CeGAdL3ABRLDLWzmKMJQ6EYow== X-Received: by 2002:a67:fa5a:: with SMTP id j26mr1220801vsq.62.1644321583148; Tue, 08 Feb 2022 03:59:43 -0800 (PST) Received: from [192.168.4.41] (072-017-018-098.res.spectrum.com. [72.17.18.98]) by smtp.gmail.com with ESMTPSA id e66sm2759749vkh.35.2022.02.08.03.59.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Feb 2022 03:59:42 -0800 (PST) Message-ID: <18eab9b6-1f77-72b2-83d3-1856c17f3fcb@joeconway.com> Date: Tue, 8 Feb 2022 06:59:41 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Robert Haas Cc: Tom Lane , Joshua Brindle , "Bossart, Nathan" , Stephen Frost , PostgreSQL-development References: <20211108204449.GO20998@tamriel.snowman.net> <5F9388A2-35EA-4DAA-BE05-68D55EEA6DC3@amazon.com> <0ED10807-9E7F-4BB5-9473-4668EE68AE2D@amazon.com> <4117557.1641329799@sss.pgh.pa.us> <730520.1644168290@sss.pgh.pa.us> <80af9ba7-ec24-9134-8fd9-00bf13f5c494@joeconway.com> From: Joe Conway Subject: Re: [PATCH v2] use has_privs_for_role for predefined roles In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2/7/22 12:09, Robert Haas wrote: > On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote: >> It is confusing and IMHO dangerous that the predefined roles currently >> work differently than regular roles eith respect to privilege inheritance. > > I feel like that's kind of a conclusory statement, as opposed to > making an argument. I mean that this tells me something about how you > feel, but it doesn't really help me understand why you feel that way. The argument is that we call these things "predefined roles", but they do not behave the same way normal "roles" behave. Someone not intimately familiar with that fact could easily make bad assumptions, and therefore wind up with misconfigured security settings. In other words, it violates the principle of least astonishment (POLA). As Joshua said nearby, it simply jumps out at me as a bug. ------- After more thought, perhaps the real problem is that these things should not have been called "predefined roles" at all. I know, the horse has already left the barn on that, but in any case... They are (to me at least) similar in concept to Linux capabilities in that they allow roles other than superusers to do a certain subset of the things historically reserved for superusers through a special mechanism (hardcoded) rather than through the normal privilege system (GRANTS/ACLs). As an example, the predefined role pg_read_all_settings allows a non-superuser to read GUC normally reserved for superuser access only. If I create a new user "bob" with the default INHERIT attribute, and I grant postgres to bob, bob must SET ROLE to postgres in order to access the capability to read superuser settings. This is similar to bob's access to the default superuser privilege to read data in someone else's table (must SET ROLE to access that capability). But it is different from bob's access to inherited privileges which are GRANTed: 8<-------------------------- psql nmx psql (15devel) Type "help" for help. nmx=# create user bob; CREATE ROLE nmx=# grant postgres to bob; GRANT ROLE nmx=# \q 8<-------------------------- -and- 8<-------------------------- psql -U bob nmx psql (15devel) Type "help" for help. nmx=> select current_user; current_user -------------- bob (1 row) nmx=> show stats_temp_directory; ERROR: must be superuser or have privileges of pg_read_all_settings to examine "stats_temp_directory" nmx=> set role postgres; SET nmx=# show stats_temp_directory; stats_temp_directory ---------------------- pg_stat_tmp (1 row) nmx=# select current_user; current_user -------------- postgres (1 row) nmx=# select * from foo; id ---- 42 (1 row) nmx=# reset role; RESET nmx=> select current_user; current_user -------------- bob (1 row) nmx=> select * from foo; ERROR: permission denied for table foo nmx=> set role postgres; SET nmx=# grant select on table foo to postgres; GRANT nmx=# reset role; RESET nmx=> select current_user; current_user -------------- bob (1 row) nmx=> select * from foo; id ---- 42 (1 row) 8<-------------------------- Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development