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 1nwpEq-00037A-3u for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jun 2022 18:08:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nwpEp-0004Yr-29 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jun 2022 18:08:03 +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 1nwpEo-0004Yi-P2 for pgsql-hackers@lists.postgresql.org; Thu, 02 Jun 2022 18:08:02 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nwpEm-0002OE-4N for pgsql-hackers@postgresql.org; Thu, 02 Jun 2022 18:08:02 +0000 Received: by mail-il1-x12e.google.com with SMTP id v7so3916128ilo.3 for ; Thu, 02 Jun 2022 11:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IJis0lr/sQrEh7yAkkUA0azyGxQup6ECO8DrFluZn+Y=; b=O4ti7WEo6QZXXISTXyBLb9sDkRWVSFmzsejoPKJI4yRAFIDfbOQ42VbSl4iTjzAMSO yQ1lKRf5F9M7qDxbGEzNXL5bJ0/GQqKIArQeiFoCFZF3NZEuC+NjY2eM196VCV61Zpz0 2F1TiCMgo6JWvSna5bo302BZjEOgGl8fBMAM2gyTJV6CGv4ESdXLSPxXr0KZlBo1BSLn MitW4e0ZeBxkxsXJTe+c+Uowb5XlIzz1OUs9qzalryxXDuJG1TXmG9kQ30qZAAZScgym VXgUPz6+vXAOQnvKi+I846Dv6LTf9UgtrTe0Vj/6YjiVYJKFPMU3oWOAPyv4P22gbZPB CSQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IJis0lr/sQrEh7yAkkUA0azyGxQup6ECO8DrFluZn+Y=; b=jDW4aV5T0raOMjCT+ltH5F+GFnb9WHsJDgK1OPs5KFHs/cc0sMePqdoIa0rb2k3Y/7 2HVeEsslPPhNpHvGrRSCyKHLtuXRgmWUWD7QJoj6BFFgycytCi4OdQgGfysr3RpcXY9D 6SEsRKoK4bsgGauTu1YjjXcI7o+wFNhYEqyI9J7u1xwIfCSmUygBDTxZqu4zz3+FpwVG FyIDEXTJiQjiu68bhzdIBkQCRqasPWBRY4f10l5CmmpvBLu+7njq49l+0CGYdR/tLvVv H+uRHoh0OQvCtKhhiD/QS9qrImgCVekeYjvukGUXG5B+2EXX71idNc1jnZ8HG5JLF7vm TI4A== X-Gm-Message-State: AOAM531jkhm1gCHdKAj4J//l7Wp93dun5K+GfRU3nrjkRDPHGue4eAaU ZXs0cklRWuMztSMZ+8MkTnwcbUAQ0WE= X-Google-Smtp-Source: ABdhPJz8i1CvorymrtHRflhzE8cJKIsz87MofwoLO0IWD0/oP85rVajkW2b1waaakzAQW3R/EjqFPg== X-Received: by 2002:a05:6e02:174c:b0:2d3:c1e2:36fe with SMTP id y12-20020a056e02174c00b002d3c1e236femr4235783ill.121.1654193277868; Thu, 02 Jun 2022 11:07:57 -0700 (PDT) Received: from nathanxps13 ([2600:1700:48f8:340f:1faa:b54b:c94f:95af]) by smtp.gmail.com with ESMTPSA id k1-20020a023341000000b003314f874ac8sm1473235jak.36.2022.06.02.11.07.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 11:07:57 -0700 (PDT) Date: Thu, 2 Jun 2022 11:07:55 -0700 From: Nathan Bossart To: Robert Haas Cc: Joe Conway , Tom Lane , "Bossart, Nathan" , Stephen Frost , PostgreSQL-development Subject: Re: replacing role-level NOINHERIT with a grant-level option Message-ID: <20220602180755.GA2402942@nathanxps13> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Jun 02, 2022 at 12:26:48PM -0400, Robert Haas wrote: > On Mon, Feb 7, 2022 at 11:13 AM Joe Conway wrote: >> > It seems to me that the INHERIT role flag isn't very well-considered. >> > Inheritance, or the lack of it, ought to be decided separately for >> > each inherited role. However, that would be a major architectural >> > change. >> >> Agreed -- that would be useful. > > Is this a kind of change people would support? Here's a quick sketch: Yes. > The idea here is that, today, a role must either inherit privileges > from all roles of which it is a member or none of them. With this > proposal, you could make a role inherit some of those privileges but > not others. I think it's not difficult to see how that might be > useful: for example, user A could be granted non-login role X with > inheritance and login role B without inheritance. That would allow > user A to exercise the privileges of a member of group X at all times, > and the privileges of user B only with an explicit SET ROLE operation. > That way, A is empowered to act for B when necessary, but won't > accidentally do so. I think we should also consider replacing role attributes with predefined roles. I'm not sure that this proposal totally prepares us for such a change, given role attributes apply only to the specific role for which they are set and aren't inherited. ISTM in order to support that, we'd need even more enhanced functionality. For example, if I want 'robert' to be a superuser, and I want 'joe' to inherit the privileges of 'robert' but not 'pg_superuser', you'd need some way to specify inheriting only certain privileges possessed by an intermediate role. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com