Dear Tom,
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
Dear Stephen,
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.
I really disagree with you here. I feel it
Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
I really disagree with you here. I feel it makes much more sense to do
this in stages, first user/group - roles, then roles-per-catalog, which
means you can then have both per-catalog 'users' and per-catalog
'groups', if you want to limit
Fabien COELHO [EMAIL PROTECTED] writes:
Moreover, a working per-cluster grouping was already
available.
Only for sufficiently small values of working. The lack of ability
for groups to contain other groups and for groups to be the direct
owners of objects were both pretty serious
Dear Stephen,
Please outline exactly what you're really looking for. Let's drop the
idea of per-cluster users/groups/roles/whatever and instead consider
what specific capabilities you're looking for.
I think from a conceptual point of view that the ability to manage
permissions at the
Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
Please outline exactly what you're really looking for. Let's drop the
idea of per-cluster users/groups/roles/whatever and instead consider
what specific capabilities you're looking for.
I think from a conceptual point of view that the
The privilege management is about a catalog, so it better to have it in
the catalog.
Permissions are at a number of levels already: cluster, database,
schema, table. Permissions at different levels hasn't got anything to
do w/ per-catalog roles.
Sorry for not being very clear. I see two
Stupid question, but how do roles relate to our existing groups?
---
Fabien COELHO wrote:
The privilege management is about a catalog, so it better to have it in
the catalog.
Permissions are at a number of levels
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Stupid question, but how do roles relate to our existing groups?
Uhhh. There are no longer groups, they've been replaced with roles
(which can have members).
Thanks,
Stephen
signature.asc
Description: Digital signature
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Stupid question, but how do roles relate to our existing groups?
As
Bruce Momjian pgman@candle.pha.pa.us writes:
Stupid question, but how do roles relate to our existing groups?
As committed, roles subsume both users and groups: a role that permits
login (rolcanlogin) acts as a user, and a role that has members is a
group. It is possible for the same role to do
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
Yes, CREATE USER too.
Stephen
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Stupid question, but how do roles relate to our existing
On Friday 01 July 2005 13:07, Stephen Frost wrote:
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
Yes,
snip
However On Friday 01 July 2005 13:02, Stephen Frost wrote:
* Bruce Momjian (pgman@candle.pha.pa.us)
Robert Treat [EMAIL PROTECTED] writes:
Was following this conversation up till now, because these two statement seem
to contradict each other. Do we really support groups still, are is CREATE
GROUP now syntactical sugar for some for of CREATE ROLE.
CREATE GROUP and CREATE USER are both now
* Robert Treat ([EMAIL PROTECTED]) wrote:
On Friday 01 July 2005 13:07, Stephen Frost wrote:
However On Friday 01 July 2005 13:02, Stephen Frost wrote:
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Stupid question, but how do roles relate to our existing groups?
Uhhh. There are no
Fabien COELHO [EMAIL PROTECTED] 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
* Tom Lane ([EMAIL PROTECTED]) wrote:
Fabien COELHO [EMAIL PROTECTED] 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
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
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
[sorry, resent because stalled]
Dear Stephen,
Right, it's a beginning to proper 'Role' support as defined by the SQL
specification.
Ok. AFAIC remember, the specification is pretty subtle and fuzzy enough so that
there is room for little design options.
I understand your concerns here
On Thu, Jun 30, 2005 at 13:39:09 +0200,
Fabien COELHO [EMAIL PROTECTED] wrote:
The standard talks about 2 distinct concepts: USER and ROLE (4.34). I'm
not sure it is a good idea to drop the user concept to replace it by role.
If you do so, you may miss something about what roles are about.
Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
This is a very useful feature, and a key idea of the specs IMVVHO. ISTM
that the way fuse user and role misses that important point, as I have
not seen a set role in the grammar file.
'set role' is coming, sorry it wasn't in my initial
Dear Stephen,
Right, it's a beginning to proper 'Role' support as defined by the SQL
specification.
Ok. AFAIC remember, the specification is pretty subtle and fuzzy enough so
that there is room for little design options.
I understand your concerns here and while I agree with the basic
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
Dear Bruno,
The standard talks about 2 distinct concepts: USER and ROLE (4.34). I'm
not sure it is a good idea to drop the user concept to replace it by role.
If you do so, you may miss something about what roles are about.
I think it is a good idea to make users synonymous with roles with
Fabien Tom (if you're watching),
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
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
Stephen Frost [EMAIL PROTECTED] writes:
Tom, if you're watching, are you working on this? I can probably spend
some time today on it, if that'd be helpful.
I am not; I was hoping you'd deal with SET ROLE. Is it really much
different from SET SESSION AUTHORIZATION?
I'm pretty sure others
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Tom, if you're watching, are you working on this? I can probably spend
some time today on it, if that'd be helpful.
I am not; I was hoping you'd deal with SET ROLE. Is it really much
different from SET SESSION
Stephen Frost [EMAIL PROTECTED] writes:
I think one big issue is that we don't have a 'usage' database check
beyond pg_hba and so any user could get the schema definitions for any
database, which kind of sucks.
Not unless he can connect to it.
regards, tom lane
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I think one big issue is that we don't have a 'usage' database check
beyond pg_hba and so any user could get the schema definitions for any
database, which kind of sucks.
Not unless he can connect to it.
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
That's controlled by pg_hba.conf though, isn't it? The idea being that
you'd like to give some people the ability to create users/roles, but to
limit the databases those created users/roles could connect to by,
Stephen Frost [EMAIL PROTECTED] writes:
That's controlled by pg_hba.conf though, isn't it? The idea being that
you'd like to give some people the ability to create users/roles, but to
limit the databases those created users/roles could connect to by, say,
requiring they have 'usage' or
I notice that AddRoleMems/DelRoleMems assume that ADMIN OPTION is not
inherited indirectly; that is it must be granted directly to you.
This seems wrong; SQL99 has under privileges
19) B has the WITH ADMIN OPTION on a role if a role authorization
descriptor identifies the role
* Tom Lane ([EMAIL PROTECTED]) wrote:
I notice that AddRoleMems/DelRoleMems assume that ADMIN OPTION is not
inherited indirectly; that is it must be granted directly to you.
This seems wrong; SQL99 has under privileges
19) B has the WITH ADMIN OPTION on a role if a role authorization
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Attached please find files and patches associated with moving from the
User/Group system currently in place to Roles, as discussed
previously.
I have cleaned this up a bit and committed it. I normally
Hi Fabien,
* Fabien COELHO ([EMAIL PROTECTED]) wrote:
I've looked very quickly at the patch. ISTM that the proposed patch is a
reworking of the user/group stuff, which are both unified for a new role
concept where a user is a kind of role and a role can be a member of
another role. Well,
Stephen Frost [EMAIL PROTECTED] writes:
Also, I've been looking through the diff between my tree and what you
committed to CVS and had a couple comments
First, sorry about the gratuitous name changes, it helped me find
every place I needed to look at the code and think about if it needed
Stephen Frost [EMAIL PROTECTED] writes:
The code I had for this was:
if (!pg_class_ownercheck(tuple,GetUserId()) ||
!is_role_member(newowner,GetUserId()))
That needs a check for superuser though because while the test will pass
on the 'pg_class_ownercheck' side, it won't on the
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Second, looks like I missed fixing an owner check in pg_proc.c
Got it. I was wondering if there were more --- might be worth checking
all the superuser() calls.
Yeah, let's come up with a decision about what
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
That needs a check for superuser though because while the test will pass
on the 'pg_class_ownercheck' side, it won't on the 'is_role_member' side
Um, right, that was another problem I had with it --- at one point
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered the owner of the
object *after* the change, then you can change the ownership.
That
On Tue, Jun 28, 2005 at 14:52:07 -0500,
Bruno Wolff III [EMAIL PROTECTED] wrote:
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered
Stephen Frost wrote:
I can perhaps see a special case for SECURITY DEFINER functions but if
we're going to special case them I'd think we'd need to make them only
be creatable/modifiable at all by superusers or add another flag to the
role to allow that.
I agree that owner changes of SECURITY
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
On Tue, Jun 28, 2005 at 14:45:06 -0400,
Stephen Frost [EMAIL PROTECTED] wrote:
If you are the owner of the object to be changed (following the normal
owner checking rules) AND would still be considered the owner of the
object *after* the
Stephen Frost wrote:
If you're considered the owner of an object then you have access to drop
it already. You have to be a member of the role to which you're
changing the ownership. That role not having permission to create the
object in place is an interesting question. That's an issue for
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Thinking about it some more, drops wouldn't be an issue since the owner
can always drop objects.
Right.
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I
* Michael Paesold ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
If you're considered the owner of an object then you have access to drop
it already. You have to be a member of the role to which you're
changing the ownership. That role not having permission to create the
object in place is
Stephen Frost [EMAIL PROTECTED] writes:
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I think about this issue.
We have a precedent, which is that RENAME
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Bruno Wolff III ([EMAIL PROTECTED]) wrote:
Creating objects in particular schemas or databases is not something that
all roles may be able to do.
Yeah, I'm not entirely sure what I think about this issue.
48 matches
Mail list logo
