On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer volume here, this is the
Greg Smith [EMAIL PROTECTED] writes:
The approach taken here is to put all the #ifdef logic into the underlying
ACE interface (see patch [2/4]), so that the caller doesn't have to care. If
SELinux support is off then the calls turns into
void x(y) {} or
bool a(b) { return true; }
On Wed, Apr 30, 2008 at 05:33:38PM -0400, Tom Lane wrote:
you're at risk of some clients being secure and some not. I thought
what we were discussing was a server-side GUC parameter that would
disallow more than one SQL statement per PQexec.
That was certainly what I was intending, yes.
The
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
[EMAIL PROTECTED] ~]# uname -a
2.6.9-67.0.4.EL #1 Sun Feb 3 06:53:29 EST 2008 i686 athlon i386
Andrew Chernow [EMAIL PROTECTED] writes:
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
Try a date that's actually during the EDT part of the
On Thu, May 01, 2008 at 09:53:41AM -0400, Andrew Chernow wrote:
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
First, this doesn't really belong
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I am confused about the below results. The backend is in EDT but it is
converting timestamps into EST ... excluding NOW(). Regardless of the
timezone provided, the backend is dishing out EST.
Try a date that's actually during the EDT
Andrew Sullivan [EMAIL PROTECTED] writes:
The _principal_ trick with SQL injection is to fool the application
into somehow handing a ; followed by an arbitrary SQL statement.
There are of course other things one can do, but most of them are
constrained to abuse of statements your application
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
I am confused about the below results. The backend is in EDT but it
is converting timestamps into EST ... excluding NOW(). Regardless
of the timezone provided, the backend is dishing out EST.
Try a date
Gregory Stark [EMAIL PROTECTED] writes:
Andrew Sullivan [EMAIL PROTECTED] writes:
The _principal_ trick with SQL injection is to fool the application
into somehow handing a ; followed by an arbitrary SQL statement.
They're the principal trick only because they're the most convenient. If you
On Thu, May 01, 2008 at 11:26:21AM -0400, Tom Lane wrote:
1. Inexpensive to implement;
2. Unlikely to break most applications;
3. Closes off a fairly large class of injection attacks.
The cost/benefit ratio looks pretty good (unlike the idea that started
this thread...)
That's a much
On Thu, 2008-05-01 at 00:26 +0100, Sam Mason wrote:
On Wed, Apr 30, 2008 at 04:58:52PM +0100, Simon Riggs wrote:
That means we probably need to introduce new infrastructure in the tcop
or executor modules to handle queries-within-queries. This isn't
special-casing MERGE so much as
Sure, modifying the WHERE clause is still possible, but the attacker is
a lot more limited in what he can do if he can't tack on a whole new
command.
I hacked into a site like that some day to show a guy that you shouldn't
trust magicquotes (especially when you switch hosting providers and
It's May 1st, which means it's time for our second 8.4 commit fest.
I took a quick look through my inbox and added some pending patches to
http://wiki.postgresql.org/wiki/CommitFest:May
but it's entirely likely there are still some missing from the queue.
Would authors of submitted patches please
Hi,
disallow more than one SQL statement per PQexec.
I agree, it would help.
1. Inexpensive to implement
Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.
2. Unlikely to break most applications;
That's true.
3. Closes off a
Greg Smith wrote:
On Wed, 30 Apr 2008, KaiGai Kohei wrote:
[1/4] sepostgresql-pgace-8.4devel-3-r739.patch
provides PGACE (PostgreSQL Access Control Extension) framework.
http://sepgsql.googlecode.com/files/sepostgresql-pgace-8.4devel-3-r739.patch
For those overwhelmed by sheer
Thomas Mueller wrote:
Disabling literals is still the only way to actually protect from SQL
injection. Except Meredith's libdejector, which is even a bit better
as far as I see, but requires more work from the developer. I don't
count Microsoft LINQ (or Java Quaere) currently because that
Thomas Mueller [EMAIL PROTECTED] writes:
1. Inexpensive to implement
Disabling literals wouldn't be much harder to implement I believe, but
I don't know the PostgreSQL internals.
You're ignoring the client-side costs of repairing broken applications.
(If it only broke applications that were
On Thu, May 01, 2008 at 06:33:07PM +0200, PFC wrote:
But it's true that preventing multi-statements adds a layer of
idiot-proofness... a rather thin layer...
As I already said in a previous remark in this thread, I don't really
like partial security solutions.
What the no
I wrote:
Another possible answer is to change the minimum to be just 64K always.
I'm not certain that it's really sensible to tie the minimum work_mem to
BLCKSZ --- I don't think we do anything where work_mem is controlling a
pool of page buffers, do we?
I've committed this change in HEAD.
NTFS adjusts winter file times while in daylight savings
The only file times we should ever be interested in are surely epoch
times, which should be unaffected by time zones.
cheers
andrew
epoch, or at least non-timezone adjusted times, is the way every modern
FS stores file times, no
Hi!
I tried to use GDB with postgresql 8 and I didnt have success.
Can you help me?
I tried like as I did in postgresql 7.4
I run configure like this: ./configure --prefix=/usr/local/pgsql8
--enable-debug --enable-cassert --enable-depend
After, I run make, make install, initdb
After this, I tried
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, May 01, 2008 at 11:02:17PM -0300, Ana Carolina Brito de Almeida wrote:
Hi!
I tried to use GDB with postgresql 8 and I didnt have success.
Can you help me?
So, I think that have something wrong (Failed to read a valid object file
[...]
23 matches
Mail list logo
