Re: [QUESTIONS] Trouble creating view\ - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [QUESTIONS] Trouble creating view\
Date
Msg-id Pine.BSF.3.96.980216233252.228U-100000@thelab.hub.org
Whole thread Raw
Responses Re: [QUESTIONS] Trouble creating view\  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Moved to pgsql-hackers@postgresql.org


On Mon, 16 Feb 1998, Bruce Momjian wrote:

> Sure doesn't, but I think it is the same problem with pg_database.  The
> problem is that there is no permission control over tables finer than
> insert/delete/update permissions.  That is, if you say someone can add
> and delete views by inserting/deleting in pg_rewrite, there is no way to
> prevent him from deleting other people's views, at least as it is now
> set up.
>
> With pg_database, people used to be able to create databases, but not
> delete them, that is, we gave them insert permission, but no delete
> permission.  But that meant people could create databases, but not
> delete them.  In 6.3, I enabled normal users with create database
> permission to delete databases, but now they can delete anyone's
> database, or at least the record in pg_database if they directly modify
> pg_database rather than trying the 'drop database' command.
>
> No way around that as the current system is configured, and I am not
> sure how to fix this.
>
> With pg_rewrite, the problem is harder because we don't have a 'is able
> to create views' permission that we can give permission to certain
> people.

    Every database/table/view has an owner associated with them, no?
Can a check not be put in that checks the owner of the database/table/view
against who is trying to delete it, with pg_superuser having "override"
privileges? Obviously, the security level of the database itself comes
into play, but we have most (if not all?) of those in place and settable
by the administrator...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org


pgsql-hackers by date:

Previous
From: "Vadim B. Mikheev"
Date:
Subject: Re: Subselects open issue Nr. NEW
Next
From: Michael Hirohama
Date:
Subject: Re: [HACKERS] Re: Subselects open issue Nr. NEW