* Jaime Casanova (jcasanov(at)systemguards(dot)com(dot)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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-01-13 19:27:58|
|Subject: Re: Deadlock in vacuum (check fails) |
|Previous:||From: Robert Haas||Date: 2010-01-13 19:21:32|
|Subject: Re: NEED HELP !|