Re: [PATCHES] Change Ownership Permission Checks

2005-07-15 Thread Tom Lane
Stephen Frost <[EMAIL PROTECTED]> writes:
> When writing this patch it occurred to me that we nuke our
> member-of-role cache for one-off lookups on occation.  I don't
> particularly like that, especially when we *know* it's a one-off lookup,

Yeah.  What I had been thinking about is that maybe it shouldn't be just
a one-element cache.  At the moment though we have no performance data
to justify complicating matters (heck, not even any to prove we need a
cache at all...)  It'd be smart to try to profile some realistic cases
before spending any time coding.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [PATCHES] Change Ownership Permission Checks

2005-07-15 Thread Stephen Frost
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> >   Attached please find a patch to change how the permissions checking
> >   for alter-owner is done.  With roles there can be more than one
> >   'owner' of an object and therefore it becomes sensible to allow
> >   specific cases of ownership change for non-superusers.
> 
> Applied with minor revisions.  The patch as submitted suffered a certain
> amount of copy-and-paste-itis (eg, trying to use pg_type_ownercheck on
> an opclass), and I really disliked using ACLCHECK_NOT_OWNER as the way
> to report "you can't assign ownership to that role because you are not
> a member of it".  So I made a separate error message for that case.

Great, thanks!  Sorry about the copy-and-paste-itis...  Must have been a
case I wasn't sure about.  The different error message makes perfect
sense.  I see you also did the superuser-in-every-role change that I had
included, thanks.

When writing this patch it occurred to me that we nuke our
member-of-role cache for one-off lookups on occation.  I don't
particularly like that, especially when we *know* it's a one-off lookup,
so I was considering adding a function for the one-off lookup case but
I couldn't come up with a way to avoid a fair bit of mostly-the-same
code as the current cache-regen code, without making the cache-regen
code alot slower which would negate the point.

Just some thoughts.

Thanks again,

Stephen


signature.asc
Description: Digital signature


Re: [PATCHES] Change Ownership Permission Checks

2005-07-14 Thread Tom Lane
Stephen Frost <[EMAIL PROTECTED]> writes:
>   Attached please find a patch to change how the permissions checking
>   for alter-owner is done.  With roles there can be more than one
>   'owner' of an object and therefore it becomes sensible to allow
>   specific cases of ownership change for non-superusers.

Applied with minor revisions.  The patch as submitted suffered a certain
amount of copy-and-paste-itis (eg, trying to use pg_type_ownercheck on
an opclass), and I really disliked using ACLCHECK_NOT_OWNER as the way
to report "you can't assign ownership to that role because you are not
a member of it".  So I made a separate error message for that case.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[PATCHES] Change Ownership Permission Checks

2005-06-29 Thread Stephen Frost
Greetings,

  Attached please find a patch to change how the permissions checking
  for alter-owner is done.  With roles there can be more than one
  'owner' of an object and therefore it becomes sensible to allow
  specific cases of ownership change for non-superusers.

  The permission checks for change-owner follow the alter-rename
  precedent that the new owner must have permission to create the object
  in the schema.

  The roles patch previously applied did not require the role for 
  which a database is being created to have createdb privileges, or for
  the role for which a schema is being created to have create
  privileges on the database (the role doing the creation did have to
  have those privileges though, of course).

  For 'container' type objects this seems reasonable.  'container' type
  objects are unlike others in a few ways, but one of the more notable
  differences for this case is that an owner may be specified as part of
  the create command.

  To support cleaning up the various checks, I also went ahead and
  modified is_member_of_role() to always return true when asked if a
  superuser is in a given role.  This seems reasonable, won't affect
  what's actually seen in the various tables, and allows us to eliminate
  explicit superuser() checks in a number of places.

  I have also reviewed the other superuser() calls in
  src/backend/commands/ and feel pretty comfortable that they're all
  necessary, reasonable, and don't need to be replaced with 
  *_ownercheck or other calls.

  The specific changes which have been changed, by file:
  aggregatecmds.c, alter-owner:
alter-owner checks:
  User is owner of the to-be-changed object
  User is a member of the new owner's role
  New owner is permitted to create objects in the schema
  Superuser() requirement removed

  conversioncmds.c, rename:
rename-checks:
  Changed from superuser() or same-roleId to pg_conversion_ownercheck
alter-owner checks:
  User is owner of the to-be-changed object
  User is a member of the new owner's role
  New owner is permitted to create objects in the schema
  Superuser() requirement removed

  dbcommands.c:
Moved superuser() check to have_createdb_privilege
Cleaned up permissions checking in createdb and rename
alter-owner checks:
  User is owner of the database
  User is a member of the new owner's role
  User has createdb privilege

  functioncmds.c:
alter-owner checks:
  User is owner of the function
  User is a member of the new owner's role
  New owner is permitted to create objects in the schema

  opclasscmds.c:
alter-owner checks:
  User is owner of the object
  User is a member of the new owner's role
  New owner has permission to create objects in the schema

  operatorcmds.c:
alter-owner checks:
  User is owner of the object
  User is a member of the new owner's role
  New owner has permission to create objects in the schema

  schemacmds.c:
Cleaned up create schema identify changing/setting/checking
(This code was quite different from all the other create functions,
 these changes make it much more closely match createdb)
alter-owner checks:
  User is owner of the schema
  User is a member of the new owner's role
  User has create privilege on database

  tablecmds.c:
alter-owner checks:
  User is owner of the object
  User is a member of the new owner's role
  New owner has permission to create objects in the schema

  tablespace.c:
alter-owner checks:
  User is owner of the tablespace
  User is a member of the new owner's role
  (No create-tablespace permission to check, tablespaces must be
   created by superusers and so alter-owner here really only matters
   if the superuser changed the tablespace owner to a non-superuser
   and then that non-superuser wants to change the ownership to yet
   another user, the other option would be to continue to force
   superuser-only for tablespace owner changes but I'm not sure I
   see the point if the superuser trusts the non-superuser enough to
   give them a tablespace...)

  typecmds.c:
alter-owner checks:
  User is owner of the object
  User is a member of the new owner's role
  New owner has permission to create objects in the schema

  Many thanks.  As always, comments, questions, concerns, please let me
  know.

Thanks again,

Stephen
? src/backend/commands/.typecmds.c.swp
Index: src/backend/commands/aggregatecmds.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/commands/aggregatecmds.c,v
retrieving revision 1.27
diff -c -r1.27 aggregatecmds.c
*** src/backend/commands/aggregatecmds.c28 Jun 2005 05:08:53 -  
1.27
--- src/backend/commands/aggregatecmds.c29 Jun 2005 15:29:57 -
***
*** 299,307