* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Fabien COELHO <coelho@cri.ensmp.fr> writes:
> >> Right, this can be done now.
> > There is the namespace collision issue, and although I might grant a
> > student the privilege to create simple roles, I would not allow them to
> > create new users for a basic practice;-)
>
> Why not? With the setup Stephen suggests, they could create only new
> users that could only get into their own database (since they'd not be
> able to grant connect rights to other databases).
I'm curious why not too... One issue I can think of is that
alter role ... rename, etc could be a problem.
> We probably need to think a bit harder about the meaning of CREATEROLE
> though. Right now it gives free license not only to create roles but
> to alter any property of existing roles. This seems appropriate if you
> think of it as a "safer form of superuser", which is how I was thinking
> of it. It would be too powerful for Fabien's situation though.
Well, what about it makes it 'too powerful'? I think that's pretty much
the same question you're asking Fabien above. I agree that only certain
properties should probably be modifiable though, one inparticular that
comes to mind is 'LOGIN'; I can see why you might want to allow only roles
which can't log in to be creatable by a given role.
It strikes me that it'd make some sense to have independent grant
control over each of the fields in pg_authid. It would also make sense
to limit the power of alter role to certain roles based on who they were
created by (superuser vs. createrole). It seems we probably need at
least an association to either catalog or creator for each role which
could then be used to limit alter role commands. catalog probably makes
more sense in the long run, creator would be easier in the short-term.
Thanks,
Stephen