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 1srgqk-003o9E-1s for pgsql-general@arkaria.postgresql.org; Fri, 20 Sep 2024 16:51:18 +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 1srgqi-009x7r-1M for pgsql-general@arkaria.postgresql.org; Fri, 20 Sep 2024 16:51:17 +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 1srgqh-009x7j-Mi for pgsql-general@lists.postgresql.org; Fri, 20 Sep 2024 16:51:17 +0000 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1srgqe-000DVk-Ut for pgsql-general@postgresql.org; Fri, 20 Sep 2024 16:51:16 +0000 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5c5b6161022so347515a12.3 for ; Fri, 20 Sep 2024 09:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726851074; x=1727455874; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dX79Lk8uAV92L3IV6qtsPsUDqmoRZ6yd8kh/PtCnOMk=; b=N8KzXwMSOjnp6xJBfO46hwpLsaWaNWgxmx55Z1J4Ls1wB10CCLY1SYrzKWqu1I0UCC 5NodzL3SzMvs5ybK0C4hcvk/5+UkZ+FkjqqAZb1eohSaB6PL1QRKPqZqM2Ey0po7sweF sMtDTMpRI4gw3pgZ8BzJJvIyaR9RfVDN12uuL8Z7tzD6FDWYjZAqV6QHlGpH2il4D22S Z4k1IVlkPJI42aLlLfB7nlTIqdrN0/QFveFBRitWX/NxCjnf6IAydtaf7Og+kh5abQE7 qZqePLLjUyWZKqLNZNxhYTpSl9aIBVut3ZkAAkXyje1LJj4ugwkLB+wnbQbGex+JEdiK Bp+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726851074; x=1727455874; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dX79Lk8uAV92L3IV6qtsPsUDqmoRZ6yd8kh/PtCnOMk=; b=tAaTcbK5j+o1khYbPay5HQQyXGoV0wpAk7B7ZNFzfPF2RVPbH4oFgkQEHzFrJYluE3 4Kun6bsqpzZi+5+MDl2L8sdqwrY5OuOWRsOno4tDCv64JCO4AGZysxIJwgkU2SBBRCoe UGqiYF8/lBbtUmfp1093aMRn4h0y7/rI9DQOQVkT/5VPtWLPl0nm7kQQFKkZiOO1MKjx 37xMZEcaFKI1A0HBZTQZ5as6JKhPNTJ15HIS5qBXz9HTXVk0PkbWEWcJvZXeeBuz9OLV 2yoxOJF7/ZK2mVti4FRiy4imvIbBcJ1UrrdPAXerHshmIBV9ecCbUeffX3O+6YrxAXUW xkzQ== X-Forwarded-Encrypted: i=1; AJvYcCVCHgKH8brLTzhQ5nwv3FMwqCojnE/wnA4yF0bgXmpQx6yZVEx3hCXNmnVN7ZqpLdEhqBv8bsJNcjXor1NB@postgresql.org X-Gm-Message-State: AOJu0YyrL25Ngg8qtbeTrTmFPCYyCSntjl+R0LDf6sn38nDzl9Gkz88L L66ww5dZSgqGPFEWAoaX842TMZVam9ZY9Ehr2JN/tLI7t2CIVEita4aIFeYIb7IVeoUpiWFUPtn +Hs6xclpVDOf1zHgydyryxTElUrs= X-Google-Smtp-Source: AGHT+IGUUZqYC1D/zT6tl5ZkItwcv5mNSA3sAhId11Fbrc+xty39My6KZmNIinw5fclaekrt2ttAOUoYOPuAL11t5qI= X-Received: by 2002:a17:907:efc7:b0:a8d:439d:5c25 with SMTP id a640c23a62f3a-a90d4fdfe99mr324271866b.4.1726851073499; Fri, 20 Sep 2024 09:51:13 -0700 (PDT) MIME-Version: 1.0 References: <42cf78d42a376bf05ca9f5776ad29edc30e784d5.camel@cybertec.at> In-Reply-To: <42cf78d42a376bf05ca9f5776ad29edc30e784d5.camel@cybertec.at> From: Robert Haas Date: Fri, 20 Sep 2024 12:51:01 -0400 Message-ID: Subject: Re: Why no pg_has_role(..., 'ADMIN')? To: Laurenz Albe Cc: Dominique Devienne , pgsql-general@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Sep 20, 2024 at 12:37=E2=80=AFPM Laurenz Albe wrote: > > But knowing whether DROP ROLE will work, > > w/o invalidating the current transaction, > > seems like something quite useful to know now, no? > > > > I can query pg_auth_members for admin_option, > > but only easily for direct membership. Taking into > > account indirect membership, which I assume applies, > > is exactly why pg_has_role() exists, no? > > That would be a useful addition, yes. I think this already exists. The full list of modes supported by pg_has_role() is listed in convert_role_priv_string(). You can do something like pg_has_role('alice', 'USAGE WITH ADMIN OPTION'). This is not new: it worked in older releases too, but AFAIK it's never been mentioned in the documentation. However, the precise rule for DROP ROLE in v16+ is not just that you need to have ADMIN OPTION on the role. The rule is: 1. You must have ADMIN OPTION on the target role. 2. You must also have CREATEROLE. 3. If the target role is SUPERUSER, you must be SUPERUSER. If I'm not wrong, pg_has_role(..., 'USAGE WITH ADMIN OPTION') will test #1 for you, but not #2 or #3. --=20 Robert Haas EDB: http://www.enterprisedb.com