Dear Tom,
> > Due to how ACL are defined in SQL, I restate my suggestion that the super
> > user should be able to change ANY right, including the GRANTOR field,
>
> I'm unconvinced of this: that philosophy soon leads you into allowing
> the superuser to create self-inconsistent sets of rights, s
On Wed, Jun 02, 2004 at 10:54:36PM +0800, Christopher Kings-Lynne wrote:
> >Well, the spec doesn't have create permissions per se, but they do have
> >a "usage" right on domains, and they specify that revoking that results
> >in dropping objects:
> >
> > 7) For every abandoned domain descri
How about pg_dumpall dumps all users as superusers, and then changes
them back to what they're supposed to be at the bottom of the script :)
Leaves you in kind of a dangerous state if the script doesn't complete,
doesn't it?
If your script doesn't complete, it can leave you in all sorts of bad
s
Someone else suggested having pg_dump dump all objects without ownership
(so, on restore, they'd all initially be owned by the user running the
script, hopefully a superuser) and then doing ALTER OWNERs and GRANTs at
the bottom.
Actually, this would probably only be reasonable if you fixed the ACLs
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Someone else suggested having pg_dump dump all objects without ownership
>> (so, on restore, they'd all initially be owned by the user running the
>> script, hopefully a superuser) and then doing ALTER OWNERs and GRANTs at
>> the bottom.
> Act
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How about pg_dumpall dumps all users as superusers, and then changes
> them back to what they're supposed to be at the bottom of the script :)
Leaves you in kind of a dangerous state if the script doesn't complete,
doesn't it?
Someone else su
Well, the spec doesn't have create permissions per se, but they do have
a "usage" right on domains, and they specify that revoking that results
in dropping objects:
7) For every abandoned domain descriptor DO, let S1.DN be the
of DO. The following is
effectively e
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> The problem here is not with pg_dump; the problem is that dropping
>> privileges doesn't cascade to dropping objects that are dependent on
>> those privileges. AFAICS the SQL spec requires us to be able to do
>> the latter.
> The spec really
The problem here is not with pg_dump; the problem is that dropping
privileges doesn't cascade to dropping objects that are dependent on
those privileges. AFAICS the SQL spec requires us to be able to do
the latter.
The spec really requires that?? So basically we have RESTRICT and
CASCADE on REV
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I think we need a proper 'effective user' facility.
> At the moment, there's breakage if a super user creates a language, then
> drops their superuser privs, then the dump cannot be restored.
The problem here is not with pg_dump; the problem
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Due to how ACL are defined in SQL, I restate my suggestion that the super
> user should be able to change ANY right, including the GRANTOR field,
I'm unconvinced of this: that philosophy soon leads you into allowing
the superuser to create self-inconsist
On Wed, 2004-06-02 at 18:44, Christopher Kings-Lynne wrote:
> > REVOKE ALL ON TABLE foo FROM GRANTOR [USER] alice;
> >
> > The super user must really be a *super* user.
>
> I think we need a proper 'effective user' facility.
>
> At the moment, there's breakage if a super user creates a language,
REVOKE ALL ON TABLE foo FROM GRANTOR [USER] alice;
The super user must really be a *super* user.
I think we need a proper 'effective user' facility.
At the moment, there's breakage if a super user creates a language, then
drops their superuser privs, then the dump cannot be restored.
All other fa
Dear Tom,
> [...]
> Even more interesting, the superuser can't fix it either,
Due to how ACL are defined in SQL, I restate my suggestion that the super
user should be able to change ANY right, including the GRANTOR field, with
an appropriate syntax, something like:
REVOKE ALL ON TABLE foo FROM
I've noticed yet another hole in our handling of object permissions,
which is that ALTER OWNER doesn't modify the object ACL list at all.
This leads to unpleasant results. For example, in CVS tip:
regression=# \c - alice
You are now connected as new user "alice".
regression=> create table atable
15 matches
Mail list logo
