Re: [PATCHES] Users/Groups -> Roles - Mailing list pgsql-hackers

Dear Stephen,

Thanks again on working on this feature.

> Role right resolution starts from the user and then works backwards up 
> the tree, with multi-level resolution.  It wouldn't go past the logged 
> in user since that's really where it starts.

ISTM that the starting point should *not* be the user, but the 
CURRENT_ROLE, which must be something distinct: Even if I'm root, if a 
'SET ROLE very_limited_privileges' is performed, then the privileges in 
effect are those of the chosen role. That is what is told by section
4.34.1.1 "SQL-session authorization identifiers" of the SQL 2003 specs as 
I understand it.

If the user is kind of a role, then I'm afraid the whole point may be
missed. But maybe not, it would depend on the implementation details.

>> So for me we should have per-cluser users as they where up to now,
>> per-catalog roles with the properties I described, and possibly
>> per-cluster group just for the sake of compatibility/simplicity of the
>> access control and managing group of users as a whole. ROLE should not
>> replace USER/GROUP. It should be added next to it.
>
> I don't see much point in having USER or GROUP when we have roles.

Indeed, if you have per-cluster ROLE, you don't need GROUP anymore.

If USER is per-cluster for connection management and ROLE per-catalog for 
database access management, then you will need a per-cluster grouping
(say for pg_hba.conf...) which is just the current GROUP.

> Is there something specific that you feel can't be done with roles that 
> could be done w/ USER/GROUP?

No, it is the reverse: I'm afraid that the way it seems to be heading, no 
more will be done with role than with group before.


> Per-catalog roles is an interesting idea, but I'd tend to think that if 
> you want per-catalog roles, you'd want per-catalog users too.

I'm fine with per-cluster users.


> I just went through the spec yesterday, check -hackers for my email

Ok, I'm going to look into that.


> about what CVS head supports vs. what's in the SQL spec.  I don't see
> any particular reason why we wouldn't be able to fully support 'Basic
> roles' and 'Extended roles' in 8.1, I think we're quite close now...

I'm looking forward to the 'SET ROLE' implementation. If the 
interpretation of the privileges is restricted to the current role, then 
I'll be happy.

I still think that removing groups and having per-cluster roles is not a 
good idea. The better way would be to keep user/group and add per-catalog 
roles. There is an opportunity which is being missed, and that won't show 
up later. Well, I can see that I'm pretty alone to think that;-)

Thanks for your answer, have a nice day,

-- 
Fabien.