Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Maybe this is too radical, but why not merge "user" and "group" into one
> animal? Both exist to bear privileges. The only difference is that
> groups can contain other bearers of privileges, but then a user is just a
> special case with zero members. Once you allow groups to have the
> possibilities that users currently have (createdb privilege, object
> ownership), there is no difference left. Of course, one such "animal"
> would be the session user and interact with pg_hba.conf, but that is just
> an ID, which may as well be a group.
We could make them essentially the same kind of thing, but include a
flag column in the table saying whether anyone is allowed to actually
log in as this entity. If the flag isn't on, the entity can own tables
and have members and so forth, but it can never be the value of
session_user.
In some circumstances I could see it making sense to allow logging in
directly as a group/role/whatchacallit. In other cases you might want
a policy that one must log in as oneself --- compare the common Unix
practice that you must 'su' to root, not log in directly as root.
So it seems to make sense to allow the login flag to be on or off
independently of whether the entity has members.
It sounds like a reasonable idea to me. We could preserve backwards
compatibility for most client-side code by making pg_shadow and pg_group
be views of the merged table.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
