On Tue, 29 Apr 2008 01:03:33 +0200, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Apr 29, 2008 at 7:00 AM, PFC [EMAIL PROTECTED] wrote:
I have found that the little bit of code posted afterwards did
eliminate
SQL holes in my PHP applications with zero developer pain, actually it
is
MORE
Am Montag, 28. April 2008 schrieb Martijn van Oosterhout:
As one of those confused, it would be really nice if someone could
summarise it all on a wiki page that we can point people to.
http://wiki.postgresql.org/wiki/TrackerDiscussion
--
Sent via pgsql-hackers mailing list
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless complication. Readline uses exactly the same ioctl()
call to determine the columns, so if ioctl() were to fail, then COLUMNS would
be unset or
OK,
Thank you for the explanation, I hope this will be implemented in future.
We will try and find a workaround to this issue until then.
Denis
- Original Message -
From: Heikki Linnakangas [EMAIL PROTECTED]
To: dv @ nabble [EMAIL PROTECTED]
Cc: pgsql-hackers list
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless complication. Readline uses exactly the same ioctl()
call to determine the columns, so if ioctl()
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Heikki Linnakangas [EMAIL PROTECTED]
Cc: dv @ nabble [EMAIL PROTECTED]; pgsql-hackers list
pgsql-hackers@postgresql.org
Sent: Monday, April 28, 2008 5:07 PM
Subject: Re: [HACKERS] SRF in SFRM_ValuePerCall mode
Heikki
Hi,
Meredith's libdejector
1) The last activity was 2005-12-17 :-(
2) From the docs: the techniques used ... are ... being explored for
patentability.
3) The tool validates the SQL statement. This is not required when
using parameterized queries.
4) An 'exemplar' query is required for each
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless complication. Readline uses exactly the same ioctl()
call to determine the columns, so if ioctl() were to fail,
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
but that seems confusing.
We could always read COLUMNS early on before readline is initialized and
stash
the value away in
Hello,
I want to collect various statistics like time taken, number of context
switches, page faults etc.. for a query being run. postgres.c contains lots of
getrusage related things.
Is there any way to calculate all the things without writing any custom code ?
Thanks and regards,
Suresh
On Tue, Apr 29, 2008 at 01:37:37PM +0200, Thomas Mueller wrote:
any literal (i.e. not just strings) can be quoted, think of dates in
queries.
The problem is not only quotes. The problem is all kinds of user
input. For example: sql = SELECT * FROM ORDERS WHERE ORDER_ID = +
orderId; This
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
Yeah, it looks like your most recent patch still has the bug that if the user
specifies wrapped there are some
Hi,
I'm writing a small program to recover specific tables from a severely
crippled database, and while I'm able to identify most fields on a hex
dump of the table file, there are several 'gaps' (probably headers and
footers and/or additional info) that I can't identify. Where can I find
zero developer pain
Actually it's not zero pain, but the main problem is: there is no way
to enforce using it.
Sure, there is no way to enforce it (apart from grepping the source for
pg_query() and flogging someone if it is found), but is it really
necessary when the right solution is
Thomas Mueller [EMAIL PROTECTED] writes:
Also, programming languages such as Java don't support tainting. And it's
again in the hand of the developer to use it, not use it, or use it in the
wrong way. There should be a way for an admin to enforce using it, and using
it correctly.
I bet you
On Tue, Apr 29, 2008 at 02:19:24PM +0100, PontoSI - Consultoria, Informática e
Serviços LDA wrote:
I'm writing a small program to recover specific tables from a severely
crippled database, and while I'm able to identify most fields on a hex
dump of the table file, there are several 'gaps'
PontoSI - Consultoria, Informática e Serviços LDA wrote:
I'm writing a small program to recover specific tables from a severely
crippled database, and while I'm able to identify most fields on a hex
dump of the table file, there are several 'gaps' (probably headers and
footers and/or
On Tue, Apr 29, 2008 at 12:25 AM, Thomas Mueller
[EMAIL PROTECTED] wrote:
What do you think about it? Do you think it makes sense to implement
this security feature in PostgreSQL as well? If not why not? Does
PostgreSQL have another solution or plan to solve the SQL injection
problem?
dv @ nabble [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
If you're not joining to the function result, and you don't need the
ability to determine its result type on the fly, you could declare it
as returning a specific rowtype and then call it in the targetlist:
select vpc();
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
..., example: CREATE
Tom Dunstan [EMAIL PROTECTED] writes:
Damn, am I the only person who likes the idea?
Just about. The reason that this idea isn't going anywhere is that its
cost/benefit ratio is untenably bad. Forbidding literals will break
absolutely every SQL-using application on the planet, and in many
Tino Wildenhain wrote:
Hi,
In C the best practice is to use #define for constants. In C++ you
have 'const', in Java 'static final'. Unfortunately the 'named
constant' concept doesn't exist in SQL. I think that's a mistake. I
suggest to support CREATE CONSTANT ... VALUE ... and DROP CONSTANT
* Tom Lane [EMAIL PROTECTED] [080429 10:59]:
Tom Dunstan [EMAIL PROTECTED] writes:
Damn, am I the only person who likes the idea?
Just about. The reason that this idea isn't going anywhere is that its
cost/benefit ratio is untenably bad. Forbidding literals will break
absolutely every
Magnus,
Please, take a look at my implementation of stat().
It has at least two advantages: it's faster and doesn't have a bug with
local-to-UTC time conversion that native msvc's stat() has.
Maybe it will be useful.
Thank you.
-Original Message-
From: Magnus Hagander [mailto:[EMAIL
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
Peter Eisentraut wrote:
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
We do look at COLUMNS if the ioctl() fails, but not for file/pipe
output.
This is quite a useless complication. Readline uses exactly the same
ioctl() call
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Remove typename from A_Const.
I'm thinking this could be cleaned up further. The patch as applied
removes the ::int4 typename decoration that had been inserted by
makeIntConst(), while leaving in place the ::float8 decoration inserted
by
Aidan Van Dyk [EMAIL PROTECTED] writes:
That said, though *I* like the idea (and since I develop against
PostgreSQL 1st and use params for my queries I would consider it a nice
tool to keep me honest), I can easily see that the cost/benefit ratio
on this could be quite low and make it not
If you're going to ask people to do significant revision of their
apps to gain security, they're going to want it to work no matter
what database they run their apps against. This is why you need
a client-side solution such as tainting.
Or if people are going to re-write their applications
For example, some applications need to replace whole phrases:
$criteria = WHERE $var1 = '$var2'
This is a very common approach for dynamic search screens, and really not
covered by placeholder approaches.
Python, again :
params = {
'column1': 10,
'column2': a st'ring,
Hi Martijn,
The problem is not only quotes. The problem is all kinds of user
input. For example: sql = SELECT * FROM ORDERS WHERE ORDER_ID = +
orderId; This is not a problem if orderId is a number. But what if
it's a String? For example 1 AND (SELECT * FROM USERS WHERE
* Gregory Stark [EMAIL PROTECTED] [080429 14:20]:
Aidan Van Dyk [EMAIL PROTECTED] writes:
That said, though *I* like the idea (and since I develop against
PostgreSQL 1st and use params for my queries I would consider it a nice
tool to keep me honest), I can easily see that the
Tom Lane escribió:
[EMAIL PROTECTED] (Alvaro Herrera) writes:
Remove typename from A_Const.
I'm thinking this could be cleaned up further. The patch as applied
removes the ::int4 typename decoration that had been inserted by
makeIntConst(), while leaving in place the ::float8 decoration
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
I'm thinking is that we should get rid of the ::float8 decoration too,
and thereby be able to revert some of the ugly code added elsewhere such
as guc.c.
Hmm, I'm not sure but I think the typecast is needed in the guc.c code
in
Hi,
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL Server, Oracle or MySQL would look
really bad.
Thomas Mueller wrote:
Forbidding literals will break absolutely every SQL-using application on the
planet
Well, it's optional. If a developer or admin wants to use it, he will
know that it could mean some work. Even if the feature is not enabled,
it's still good to have it. And using
On Tue, Apr 29, 2008 at 04:33:01PM -0400, Andrew Dunstan wrote:
Moreover, it seems unlikely that it will even cover the field. A partial
cloak might indeed be worse than none, in that it will give some developers
an illusion of having security.
I think this is a really important point, and
Thomas,
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL Server, Oracle or MySQL would look
really bad.
[I know, I know, bad form]
On Tue, Apr 29, 2008 at 04:55:21PM -0400, Andrew Sullivan wrote:
thinking they have to worry about that area of security at all. I
think without a convincing argument that the proposal will even come
close to covering most SQL injection cases, it's a bad idea.
To
(I sort of like the
suggestion up-thread, myself, which is to have a GUC that disables
multi-statement commands. That'd probably cover a huge number of
cases, and combined with some sensible quoting rules in client
libraries, would quite possibly be enough.)
MySQL did this already.
--
On Tue, 29 Apr 2008 22:18:48 +0200 Thomas Mueller wrote:
For PostgreSQL the 'disable literals' feature would be great
publicity: PostgreSQL would be the first only major database that has
a good story regarding SQL injection. Yes it's not the magic silver
bullet, but databases like MS SQL
On Wed, Apr 30, 2008 at 1:48 AM, Thomas Mueller
[EMAIL PROTECTED] wrote:
Hi,
For PostgreSQL the 'disable literals' feature would be great
publicity:
'publicity' is something this community does not crave for, at least not
feature wise. If that were the case we would have had a million
Josh Berkus [EMAIL PROTECTED] writes:
(I sort of like the
suggestion up-thread, myself, which is to have a GUC that disables
multi-statement commands. That'd probably cover a huge number of
cases, and combined with some sensible quoting rules in client
libraries, would quite possibly be
Greg,
Did you guys miss Tom's comment up-thread? Postgres already does this if
you use PQExecParams().
Keen. Now we just need to get the driver developers to implement it. I
imagine Java does.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
--
Sent via pgsql-hackers mailing list
In the plan below, we can see that the optimizer is sorting an already
sorted result. It seems to forget the sort order across the UNIQUE node. My
question is, do we make any attempts in the optimizer to remember the sort
order of a result, to avoid any further sorting on same sort-key? If not,
Gurjeet Singh [EMAIL PROTECTED] writes:
In the plan below, we can see that the optimizer is sorting an already
sorted result. It seems to forget the sort order across the UNIQUE node. My
question is, do we make any attempts in the optimizer to remember the sort
order of a result, to avoid any
45 matches
Mail list logo
