Re: [HACKERS] Priviliges on tables and views

> 
> Thus spake Vadim B. Mikheev
> > > CREATE VIEW passwd AS SELECT uid, login, bid, gcos, home, shell
> > >     FROM account WHERE a_active = 't';
> > > 
> > > REVOKE ALL ON passwd FROM PUBLIC;
> > > GRANT SELECT ON passwd TO PUBLIC;
> > > 
> > > Unfortunately this doesn't work.  The VIEW inherits the permissions
> > > from the table it is a view of.  It seems to me that allowing a view
> > > to define permissions separately from its parent would be a useful
> > > thing.  So, does anyone know if this behaviour is allowed by the
> > > SQL spec and if it is allowed, would this be difficult to do?
> > 
> > This is allowed by SQL and this is very useful thing. Not easy to implement:
> > views are handled by RULES - after parsing and before planning, - but
> > permissions are checked by executor (execMain.c:InitPlan()->ExecCheckPerms()).
> 
> Oh well.  Is it worth putting on the TODO list at least?  Maybe someone
> will get to it eventually.
> 
> In the meantime, how close are we to being able to update views?  I can
> do what I want that way - just make two tables with public perms on
> one but not the other and make a view for the combined table instead
> of for a subset of a table.

Certainly is a good item for the TODO list.  Added:

* Allow VIEW permissions to be set separately from the underlying tables


-- 
Bruce Momjian
maillist@candle.pha.pa.us