Re: [PATCH] remove redundant ownership checks - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [PATCH] remove redundant ownership checks
Date
Msg-id 20100113192711.GG17756@tamriel.snowman.net
Whole thread Raw
In response to Re: [PATCH] remove redundant ownership checks  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: [PATCH] remove redundant ownership checks  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List pgsql-hackers
* Jaime Casanova (jcasanov@systemguards.com.ec) wrote:
> if it's not broken, then it doesn't need a fix...
> if that code is causing a hole in security then i said remove it, if
> not... what's the problem in let it be until we know exactly what the
> plan is?

The chances of getting concensus on an overarching big plan are slim
to none, which essentially means it's not going to get changed.  I've
suggested an approach and had no feedback on it.  What's probably
needed, to get attention anyway, is a patch which starts to move us in
the right direction.  That's going to be more than a 6-line patch, but
doesn't have to be the whole thing either.

For my 2c, I think a patch which attacks 'AT_PrepCmd' and rips out all
of the owner checks from it and moves them to appropriate places (that
is to say, per my proposal, very shortly before the 'work' is actually
done, which is also often where the *other* permission checks are done,
for those pieces which require more than just a simple owner check)
would probably be the first step.

Of course, the code between AT_PrepCmd and where the permissions checks
are moved to would need to be reviewed and vetted to make sure there
isn't anything being done that shouldn't be done without permission,
but, honestly, I don't recall seeing much of that.  We're actually
pretty good about having a "gather info" stage followed by a "implement
change" stage.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby and query cancel
Next
From: Tom Lane
Date:
Subject: Re: Deadlock in vacuum (check fails)