Peter Eisentraut [EMAIL PROTECTED] writes:
Why not move it to src/tools, so no one gets the impression that it is
user code?
I thought about that earlier, but concluded it wasn't worth the loss of
CVS history.
regards, tom lane
---(end of
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe the proper way to handle this is a new directory under /tmp.
It's definitely not worth the trouble. I looked at what configure does
to make /tmp subdirectories portably, and it is spectacularly
Bruce Momjian [EMAIL PROTECTED] writes:
From a public relations perspective and a code reuse perspective I think
we should create temporary tables securely. The attached applied patch
fixes contrib/findoidjoins/make_oidjoins_check.
... and creates issues of its own, such as attempting an rm
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I believe the proper way to handle this is a new directory under /tmp.
It's definitely not worth the trouble. I looked at what configure does
to make /tmp subdirectories portably, and it is spectacularly ugly
(not to mention long).
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
From a public relations perspective and a code reuse perspective I think
we should create temporary tables securely. The attached applied patch
fixes contrib/findoidjoins/make_oidjoins_check.
... and creates issues of its own, such
On Thu, 2004-11-04 at 10:07, Bruce Momjian wrote:
My method is secure, and I think we do have to handle this in a way that
addresses the security concerns.
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
It is
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run from a directory where others have write
permission.
In which case, they
On Wed, 3 Nov 2004, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run from a directory where others
Gavin Sherry [EMAIL PROTECTED] writes:
I think the problem can really be solved by just removing it from the
distribution.
Just FYI, I've already done that in Red Hat's RPMs (not sure if Devrim
followed suit). I can't think of a good reason for make install to
install that script, either.
Gavin Sherry wrote:
On Wed, 3 Nov 2004, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think Tom's fix adequately addresses the security concerns. Exactly
what is wrong with writing to the current working directory?
Because it could be run
Neil Conway [EMAIL PROTECTED] writes:
Attached is a patch that removes the make_oidjoins_check script from
make install. Barring any objections, I'll apply it to HEAD later
today.
If we are going in that direction, all the files installed by this
subdirectory should be suppressed (ie,
On Thu, 2004-11-04 at 13:05, Bruce Momjian wrote:
I am fine with removing it but if we don't I would like to have it
secure, mostly from a public relations perspective.
A change which introduced two regressions and fails to materially
improve the security of the script is a curious definition
12 matches
Mail list logo
