Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
It's imaginable, but can you point to any real exam
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't offhand know of any Unix platforms where they cannot be found
>> out
> I don't know which platforms it is secure/insecure on, but I can
> certainly imagine secure systems where ps(1) data in general is viewed
> as sensitive and
"Tom Lane" <[EMAIL PROTECTED]> writes
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
>
> No. Remember that in most installations Assert() is a no-op.
>
Well, I still suggest to change it :(
The only chance elog(ERROR, "unrecognized hash action code") could be
triggered is the *unbelievable* prog
Tom Lane wrote:
I don't offhand know of any Unix platforms where they cannot be found
out
I don't know which platforms it is secure/insecure on, but I can
certainly imagine secure systems where ps(1) data in general is viewed
as sensitive and thus not made globally visible.
My inclination
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That test is a no-op in the case where hashp->alloc in fact points to
>> palloc. But it doesn't always point there --- see shmem_alloc.
> Perhaps it would be a net win to change ShmemAlloc() to elog(ERROR) on
> out-of-memory?
Possibly
Tom Lane wrote:
That test is a no-op in the case where hashp->alloc in fact points to
palloc. But it doesn't always point there --- see shmem_alloc.
Perhaps it would be a net win to change ShmemAlloc() to elog(ERROR) on
out-of-memory? A fair few of the ShmemAlloc() call sites don't bother to
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think that using -P for pg_autovacuum is just plain stupid, even on a
>> nominally secure single-user box.
> Assuming that command-line parameters are actually globally visible on
> your platform, which isn't necessarily the case.
I
"Neil Conway" <[EMAIL PROTECTED]>writes
> Well, element_alloc() uses the hash table's alloc function pointer. In
> theory, that could be malloc() or anything else, although I notice this
> abstraction is not consistently maintained (e.g. dir_realloc assumes
> pfree() is sufficient to free an alloc
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Change elog(ERROR) to Assert(false) for two reasons:
No. Remember that in most installations Assert() is a no-op.
> (2) even if it could happen, elog(ERROR) won't save us since in many places
> we have to check the return code of hash_search() and de
Tom Lane wrote:
The question at hand is whether we want to support an obvious security
hole. The argument that "some people will not care" applies with at
least as much force to psql or pg_dump, which at least have the grace
to not hang around and advertise their command-line parameters forever.
Qingqing Zhou wrote:
On a separate matter, can anyone please explain me how this piece of code
works:
/* no free elements. allocate another chunk of buckets */
if (!element_alloc(hashp, HASHELEMENT_ALLOC_INCR))
return NULL; /* out of memory */
element_alloc() in fact uses MemoryCo
Neil Conway <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> I think the reason there is at least some value in having this switch
>> for pg_autovacuum is that pg_autovacuum is almost exclusively used in a
>> situation in which the password can't be specified on the command-line
> Sorry, thin
Change elog(ERROR) to Assert(false) for two reasons:
(1) "unrecognized hash action code" could hardly really happen;
(2) even if it could happen, elog(ERROR) won't save us since in many places
we have to check the return code of hash_search() and decide the error
level.
On a separate matter, ca
Neil Conway wrote:
I think the reason there is at least some value in having this switch
for pg_autovacuum is that pg_autovacuum is almost exclusively used in a
situation in which the password can't be specified on the command-line
Sorry, thinko: I meant interactively via the terminal.
-Neil
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like this g
Tom Lane wrote:
I see that in fact all the PL tests are broken for vpath builds.
Fixed (copy and paste from src/test/regress) --- I can't actually
test the plpython script right now, but it should work the same
as the other two.
Thanks. I have added support for vpath builds to
Hello
This patch is implementation of some date functions which produce better
compatibility with Oracle (On request Radim Kolar). Major changes are in
/src/backend/utils/adt/oracle_compat.c. There are new functions: next_day,
last_day, add_months and months_between.
Original Oracle doc
http:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> BTW, I noticed that the PL/Perl regression tests are broken for out of
>> tree build (i.e. "vpath")...
> I see that in fact all the PL tests are broken for vpath builds.
Fixed (copy and paste from src/test/regress) --- I can't ac
Alvaro Herrera wrote:
Yes, you can register a function as "validator" during language
creation. AFAIR there are no validator functions except SQL and
plpgsql, so you would have to create one for plperl ...
Excellent. We'll definitely work on that. Not having this has annoyed me
(and I'
Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
I would argue actually that this switch is a horrible idea and we
must take it out entirely. The method Ian proposes for hiding the
password after reading it is certainly not portable in the slightest,
a
On Tue, May 24, 2005 at 11:53:45AM -0400, Andrew Dunstan wrote:
> Alvaro Herrera wrote:
>
> >On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
> >
> >Hmm, is there a way to have a validator function and have the strict
> >check at function creation too? I know these things are repo
Alvaro Herrera wrote:
On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
Andrew,
it works like this:
andrew=# create or replace function foo() returns text language plperl
as $$ $x = 1; return 'hello'; $$;
CREATE FUNCTION
andrew=# select foo();
ERROR: creation of Perl fu
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 24 May 2005 16:02
> To: Dave Page
> Cc: Ian FREISLICH; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] [PATCH] pg_autovacuum commandline
> password hiding.
>
> "Dave Page" writes:
> >> Which is exactly why
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like thi
"Dave Page" writes:
>> Which is exactly why we don't (and won't) provide such a switch.
> Err, yes we do:
Um, sorry, I totally misread Ian's patch as a proposal that we add a
password switch (I hate unidiffs ;-)).
I would argue actually that this switch is a horrible idea and we
must take it ou
On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
Andrew,
> it works like this:
>
> andrew=# create or replace function foo() returns text language plperl
> as $$ $x = 1; return 'hello'; $$;
> CREATE FUNCTION
> andrew=# select foo();
> ERROR: creation of Perl function failed: Glo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 24 May 2005 15:17
> To: Ian FREISLICH
> Cc: pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] [PATCH] pg_autovacuum commandline
> password hiding.
>
> Ian FREISLICH <[EMAIL PR
Ian FREISLICH <[EMAIL PROTECTED]> writes:
> ... The only thing is that
> pg_autovacuum keeps the password supplied on the commandline so
> anyone that does a 'ps' can get the database superuser password.
Which is exactly why we don't (and won't) provide such a switch.
Use ~/.pgpass instead.
Neil Conway wrote:
Andrew Dunstan wrote:
The current plperl regression tests do not test the trigger or shared
data features. The attached new files remedy that [...]
Applied to HEAD. Thanks for the patch.
BTW, I noticed that the PL/Perl regression tests are broken for out of
tree build
Ian FREISLICH wrote:
Does pg_autovacuum use ~/.pgpass?
Yes (any libpq-based app will).
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Neil Conway wrote:
> Ian FREISLICH wrote:
> > I'm not sure if you've done this for a later version of pg_autovacuum.
> > I'm using what came with postgres-7.4.6. For database security on
> > a shared server (~800 logins) it's best to set the superuser password
> > and not allow passwordless connec
Andrew Dunstan wrote:
The current plperl regression tests do not test the trigger or shared
data features. The attached new files remedy that [...]
Applied to HEAD. Thanks for the patch.
BTW, I noticed that the PL/Perl regression tests are broken for out of
tree build (i.e. "vpath")...
-Nei
Ian FREISLICH wrote:
I'm not sure if you've done this for a later version of pg_autovacuum.
I'm using what came with postgres-7.4.6. For database security on
a shared server (~800 logins) it's best to set the superuser password
and not allow passwordless connections. The only thing is that
pg_a
Hi
I'm not sure if you've done this for a later version of pg_autovacuum.
I'm using what came with postgres-7.4.6. For database security on
a shared server (~800 logins) it's best to set the superuser password
and not allow passwordless connections. The only thing is that
pg_autovacuum keeps the
34 matches
Mail list logo
