* 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 n
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. We
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 ne
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 'i
* 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
* 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 o
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.
Th
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 co
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 D
* 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 *af
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 SE
* 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 t
* 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
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 REN
* 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 t
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
19) B has the WITH ADMIN OPTION on a role if a role authorization
descriptor identifies the role as granted
* 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
>
> 19) B has the WITH ADMIN OPTION on a role if a role authorization
>
[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 and
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 ab
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 initia
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 ide
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
re
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 sta
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 SE
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
* 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
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 '
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 make
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
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 restric
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 datab
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 t
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 "ma
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 numb
* 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 signat
Thanks, TODO updated. We still support CREATE GROUP? It translates to
roles?
---
Tom Lane wrote:
> Bruce Momjian writes:
> > Stupid question, but how do roles relate to our existing "groups"?
>
> As committed, roles subs
Bruce Momjian 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 both things, though
* 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 writes:
> > > Stupid question, but how do roles relate to our existing "groups"?
> >
> >
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,
However On Friday 01 July 2005 13:02, Stephen Frost wrote:
> * Bruce Momjian (pgman@candle.pha.pa.u
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
* 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. The
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
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
48 matches
Mail list logo
