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 1pUBQa-0003mI-06 for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Feb 2023 19:02:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pUBQY-00059r-KB for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Feb 2023 19:02:18 +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 1pUBQY-00059i-8e for pgsql-hackers@lists.postgresql.org; Mon, 20 Feb 2023 19:02:18 +0000 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pUBQU-0000an-1g for pgsql-hackers@postgresql.org; Mon, 20 Feb 2023 19:02:15 +0000 Received: by mail-pl1-x630.google.com with SMTP id z2so2709521plf.12 for ; Mon, 20 Feb 2023 11:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=C4xP2FKyEFWkib+0ZQuKNqOKfkeExcSz/IadUjAZoRU=; b=MMUR55ihylc0/vOHa3e0p1b1JWSkseCghCb6MfpTRLQPSO55HDX29Ed9Q2TXK9M3sD CuWcNdkauGpAm4skoAgImScZpAIJnb2R/g3njegHhPj+Oo6KpAoSxYAPtpWAtoznMcbr /aGFv9+NhAQJGVfg5Fzw37AoSs2ThMU39KjDksX3RFRsy7R6manvQH3KcB7yUz0is0N2 gDhpGid5ntZIU4KLKQnSn3YnCmtmz3rlJr8C5nBftW9s1pTgCkwJE/z9ZV06ei7kUJqR 1s7AS1+FLwrT8eC6j9zZ1Czt0r++u7iuUpYeVAyWf8Zc9yoEll01P7YfkzCfvQKFZUTN A6jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C4xP2FKyEFWkib+0ZQuKNqOKfkeExcSz/IadUjAZoRU=; b=FsHs66btZ/LbU5kEDvSfokDvy7VCsKuqqMMqzS+cFIIzbRiXY39VFP+RRfMno2W8xG eah8bqAmh7eHyonI6DO3V2wayu2hp9eKJbfDQmn1eqNFJCgUjvBh/ud/M3G1dH8U2+tL i6gLuZ/EJxakXNNEEaZ6fJlO2aoOHCFCJGbRwiL0ZCoZ5z54DZbbVVhesST0wBWSyPCs Pw80sxI91LayLcZZV7yp6q+AnDZYpyYh19p1byo15cEJC2zzEyOwkqRTktq8ixYHVN30 Sfil/D3nYBuzHvMdl55qzLoVB8jBeIALZNppuQIQUU+t1zlXk1TPFshE8UpXvpH031le Samw== X-Gm-Message-State: AO0yUKX7H1D28akL9momuagOz14sTgbx8JbHec5na1tg5nc9Etej8ROs wAMXb3PxozG2QaXngxC/i1EHQNnQIhU= X-Google-Smtp-Source: AK7set+LmBTFMgGXLu1ZB6+cAK/LPHx6GQraUROJVqI0ohsc9SNz3nk720a+BNzi+WQ4zm2/Nzf7hw== X-Received: by 2002:a05:6a20:734f:b0:bf:ca3:6896 with SMTP id v15-20020a056a20734f00b000bf0ca36896mr1123438pzc.2.1676919732908; Mon, 20 Feb 2023 11:02:12 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id r17-20020a638f51000000b004f1cb6ffe81sm2785813pgn.64.2023.02.20.11.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Feb 2023 11:02:12 -0800 (PST) Date: Mon, 20 Feb 2023 11:02:10 -0800 From: Nathan Bossart To: Peter Eisentraut Cc: Alvaro Herrera , Tom Lane , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: improving user.c error messages Message-ID: <20230220190210.GA3481922@nathanxps13> References: <20230127000936.GA1998073@nathanxps13> <20230127183119.e5jtyh4g2md57ctb@alvherre.pgsql> <20230127231507.GA2221340@nathanxps13> <20230207201009.GA450353@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Feb 20, 2023 at 08:54:48AM +0100, Peter Eisentraut wrote: > I'm concerned about the loose use of "privilege" here. A privilege is > something I can grant. So if someone doesn't have the "REPLICATION > privilege", as in the above example, I would expect to be able to do "GRANT > REPLICATION TO someuser". Since that is not what is happening, we should > use some other term. The documentation around CREATE USER uses the terms > "attribute" and "option" (and also "privilege") for these things. Good point. I will adjust these to use "attribute" instead. > Similarly -- this is an existing issue but we might as well look at it -- in > something like > > must be superuser or a role with privileges of the > pg_write_server_files role > > the phrase "a role with the privileges of that other role" seems ambiguous. > Doesn't it really mean you must be a member of that role? Membership alone is not sufficient. You must also inherit the privileges of the role via the INHERIT option. I thought about making this something like must have the INHERIT option on role %s but I'm not sure that's accurate either. That wording makes it sound lіke you need to be granted membership to the role directly WITH INHERIT OPTION, but what you really need is membership, direct or indirect, with an INHERIT chain up to the role in question. However, it looks like "must have the ADMIN option on role %s" is used to mean something similar, so perhaps I am overthinking it. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com