Re: BUG #1150: grant options not properly checked

Dear Tom,

> I looked at this more carefully. In both SQL92 and SQL99, the only
> Access Rule for GRANT is
>
> 1) The applicable privileges shall include a privilege identifying
> O.
>
> Here "O" is the target object, and "applicable privileges" is all the
> privileges held by the current user.
>
> Now, that says "a privilege", not "the privilege to be granted", nor
> even "a privilege with grant option".

Ok. "identified" privilege seems to be defined in *Syntax* rule 4 and it
includes "with grant option" (section 12.2 <grant privilege statement>).

> As near as I can tell, what the spec wants is that GRANT should raise
> error if the issuing user has no privileges at all for the target
> object, but as long as he has at least one privilege bit, he gets past
> the Access Rule --- whether or not that bit has anything to do with the
> privilege bits to be granted.

Ok, I understand it finally. If it is *empty*, then it is an error, but if
it is not empty, then it proceeds with grantable privileges and warns
about ungrantable ones. What you say above.

> AFAICS the specification for REVOKE is exactly parallel.

Ok, but "identified" means there "those that are currently granted
by A" (12.7 <revoke statement> 9 case a).

> So the existing code is still wrong, but not in quite the way we thought.

Sorry. I sometimes tend to read what I expect instead of what is written
when reading a specs...

> I'd be the first to say that this aspect of the spec is a tad bizarre.

Well, we agree on that;-)

> Does anyone want to argue for ignoring the spec and implementing "saner"
> behavior? It's not like we are super close to spec compliance for
> privileges otherwise ...

I think that if pg really sticks to the spec as I finally understand it
with your help, it would not be bad. I mean with both error (empty set in
grant or revoke) and warnings (non grantable parts for grant, non granted
parts for revoke).

Thanks for your help,

--
Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr