Help | Site Map
Connecting Tech Pros Worldwide
 
 
LinkBack Thread Tools
  #1  
Old November 23rd, 2005, 02:21 AM
Vivek Khera
Guest
 
Posts: n/a
Default dangling permission on tables after drop user.

I have a database which started on Pg 7.1, moved to 7.2 via
pg_dump/restore, and ultimately to Pg 7.4 likewise.

While it was in 7.2, I added one user and granted access to various
tables. After the 7.4 migration, that user was no longer needed, so
was removed via "dropuser" command line tool.

Now, when I pg_dump that db using the version 7.4.5 tools, I cannot
restore because there are still grants in there for this phantom user:

REVOKE ALL ON TABLE partners FROM PUBLIC;
GRANT INSERT,SELECT,UPDATE,DELETE ON TABLE partners TO www;
GRANT ALL ON TABLE partners TO "102";

there is no user with ID 102 in the pg_user view. pg_restore complains
about the missing user "102". And no, the user was not "102" it was
the name of a (former) employee.

My questions are:

1) did I do something wrong in dropping that user?
2) how do I fix this in my system tables?

The gross hack is to pg_restore to an ascii file and delete those GRANT
lines, but the compressed dump is over 2Gb for this database.


Vivek Khera, Ph.D.
+1-301-869-4449 x806


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

  #2  
Old November 23rd, 2005, 02:21 AM
Richard Huxton
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.

Vivek Khera wrote:[color=blue]
>
> there is no user with ID 102 in the pg_user view. pg_restore complains
> about the missing user "102". And no, the user was not "102" it was the
> name of a (former) employee.[/color]
[color=blue]
> The gross hack is to pg_restore to an ascii file and delete those GRANT
> lines, but the compressed dump is over 2Gb for this database.[/color]

Am I missing something Vivek, or should the gross hack be "creating a
user with id=102" ?

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

  #3  
Old November 23rd, 2005, 02:21 AM
Vivek Khera
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.


On Sep 29, 2004, at 4:55 PM, Richard Huxton wrote:
[color=blue]
> Vivek Khera wrote:[color=green]
>> there is no user with ID 102 in the pg_user view. pg_restore
>> complains about the missing user "102". And no, the user was not
>> "102" it was the name of a (former) employee.[/color]
>[color=green]
>> The gross hack is to pg_restore to an ascii file and delete those
>> GRANT lines, but the compressed dump is over 2Gb for this database.[/color]
>
> Am I missing something Vivek, or should the gross hack be "creating a
> user with id=102" ?[/color]

And how exactly does one accomplish this? pg_users is a view so you
can't insert into it.


Vivek Khera, Ph.D.
+1-301-869-4449 x806


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

  #4  
Old November 23rd, 2005, 02:21 AM
Alvaro Herrera
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.

On Wed, Sep 29, 2004 at 05:07:38PM -0400, Vivek Khera wrote:[color=blue]
>
> On Sep 29, 2004, at 4:55 PM, Richard Huxton wrote:
>[color=green]
> >Vivek Khera wrote:[color=darkred]
> >>there is no user with ID 102 in the pg_user view. pg_restore
> >>complains about the missing user "102". And no, the user was not
> >>"102" it was the name of a (former) employee.[/color]
> >[color=darkred]
> >>The gross hack is to pg_restore to an ascii file and delete those
> >>GRANT lines, but the compressed dump is over 2Gb for this database.[/color]
> >
> >Am I missing something Vivek, or should the gross hack be "creating a
> >user with id=102" ?[/color]
>
> And how exactly does one accomplish this? pg_users is a view so you
> can't insert into it.[/color]

CREATE USER ... WITH SYSID 102;

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Dios hizo a Adán, pero fue Eva quien lo hizo hombre.


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

  #5  
Old November 23rd, 2005, 02:21 AM
Tom Lane
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.

Vivek Khera <khera@kcilink.com> writes:[color=blue]
> On Sep 29, 2004, at 4:55 PM, Richard Huxton wrote:[color=green]
>> Am I missing something Vivek, or should the gross hack be "creating a
>> user with id=102" ?[/color][/color]
[color=blue]
> And how exactly does one accomplish this?[/color]

CREATE USER.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

  #6  
Old November 23rd, 2005, 02:21 AM
Alvaro Herrera
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.

On Thu, Sep 30, 2004 at 09:32:30AM -0400, Vivek Khera wrote:[color=blue]
>
> On Sep 29, 2004, at 5:35 PM, Alvaro Herrera wrote:
>[color=green][color=darkred]
> >>>Am I missing something Vivek, or should the gross hack be "creating a
> >>>user with id=102" ?
> >>
> >>And how exactly does one accomplish this? pg_users is a view so you
> >>can't insert into it.[/color]
> >
> >CREATE USER ... WITH SYSID 102;[/color]
>
> Ok. I did that. So now how do I get rid of that user and all the
> grants? DROP USER ends up with the dangling GRANTs still hanging
> about.
>
> Is there no way to drop a user and have the necessary grants disappear?
> How does one drop a user cleanly?[/color]

I'm afraid you'll have to ALTER TABLE (or whatever) for each of these ...
I don't think there is a command that would help you do that
automatically. You can cheat by looking at system catalogs for the
acl column (e.g. pg_class.relacl) and using that in a function.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

  #7  
Old November 23rd, 2005, 02:25 AM
Andrew Sullivan
Guest
 
Posts: n/a
Default Re: dangling permission on tables after drop user.

On Thu, Sep 30, 2004 at 10:03:29AM -0400, Alvaro Herrera wrote:[color=blue]
>
> I'm afraid you'll have to ALTER TABLE (or whatever) for each of these ...
> I don't think there is a command that would help you do that
> automatically. You can cheat by looking at system catalogs for the
> acl column (e.g. pg_class.relacl) and using that in a function.[/color]

Andrew Hammond is about to (has?) post some helper code he has for
managing ACLs more easily.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

 

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

What is Bytes?

We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights. Get the best answers to your questions from over network members.
Post your question now . . .
It's fast and it's free

Popular Articles