On Mon, Feb 7, 2022 at 11:13 AM Joe Conway <m...@joeconway.com> 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: 1. Extend the GRANT role_name TO role_name [ WITH ADMIN OPTION ] with a new, optional clause, something like WITH NO INHERIT or WITH NOINHERIT or WITHOUT INHERIT. 2. Remove the INHERIT | NOINHERIT flag from CREATE ROLE and ALTER ROLE. 3. Replace pg_authid.rolinherit with pg_auth_members.inherit. Any place where we would have considered rolinherit, instead consider the inherit flag for the particular pg_auth_members entry at issue. 4. When dumping from an old version, dump all grants to NOINHERIT roles as non-inheritable grants. 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. It's been proposed elsewhere by Stephen and others that we ought to have the ability to grant ADMIN OPTION on a role without granting membership in that role. There's some overlap between these two proposals. If your concern is just about accident prevention, you will be happy to use this instead of that. If you want real access restrictions, you will want that, not this. I think that's OK. Doing this first doesn't mean we can't do that later. What about the reverse? Could we add ADMIN-without-membership first, and then decide whether to do this later? Maybe so, but I have come to feel that NOINHERIT is such an ugly wart that we'll be happier the sooner we kill it. It seems to make every discussion that we have about any other potential change in this area more difficult, and I venture that ADMIN-without-membership wouldn't turn out to be an exception. Based on previous discussions I think that, long term, we're probably headed toward a future where role grants have a bunch of different flags, each of which controls a single behavior: whether you can implicitly use the privileges of the role, whether you can access them via SET ROLE, whether you can grant the role to others, or revoke it from them, etc. I don't know exactly what the final list will look like, and hopefully it won't be so long that it makes us all wish we were dead, but there doesn't seem to be any possibility that implicit inheritance of permissions won't be in that list. I spent a few minutes considering whether I ought to instead propose that we just nuke NOINHERIT from orbit and replace it with absolutely nothing, and concluded that such a proposal had no hope of attracting consensus. Perhaps the idea of replacing it with that is more powerful and at least IMHO cleaner will. Thoughts? -- Robert Haas EDB: http://www.enterprisedb.com
