Thread: REMOVE

REMOVE

From
Date:
REMOVE ME FROM YOUR LIST.......

I am not wanting anymore emails from postgres

E-Mail: comptech@envirosolution.com
Web Site: www.envirosolution.com


-----Original Message-----
From: pgsql-announce-owner@postgresql.org
[mailto:pgsql-announce-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Monday, May 02, 2005 3:07 PM
To: pgsql-announce@postgresql.org
Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

Two serious security errors have been found in PostgreSQL 7.3 and newer
releases.  These errors at least allow an unprivileged database user to
crash the backend process, and may make it possible for an unprivileged
user to gain the privileges of a database superuser.

We are currently preparing new releases that will correct these problems
in freshly initdb'd installations.  However, because these problems are
really incorrect system catalog entries, updating to a new release will
NOT by itself solve the problems in an existing installation.  Instead,
it is necessary for the database administrator to fix the catalog entries
manually, as described below.  We are releasing this advisory to encourage
administrators of PostgreSQL installations to perform these fixes as soon
as possible.


Character conversion vulnerability
----------------------------------

The more severe of the two errors is that the functions that support
client-to-server character set conversion can be called from SQL commands
by unprivileged users, but these functions are not designed to be safe
against malicious choices of argument values.  This problem exists in
PostgreSQL 7.3.* through 8.0.*.  The recommended fix is to disable public
EXECUTE access for these functions.  This does not affect normal usage of
the functions for character set conversion, but it will prevent misuse.

To accomplish this change, execute the following SQL command as a
superuser:

    UPDATE pg_proc SET proacl = '{=}'
    WHERE pronamespace = 11 AND pronargs = 5
          AND proargtypes[2] = 'cstring'::regtype;

In 7.3.* through 8.0.*, this should report having updated 90 rows.
7.4 and later will report a "WARNING: defaulting grantor to user ID 1"
which can be ignored.

The above command must be carried out in *each* database of an
installation, including template1, and ideally including template0 as
well.  If you do not fix the template databases then any subsequently
created databases will contain the same vulnerability.  template1 can
be fixed in the same way as any other database, but fixing template0
requires additional steps. First, from any database issue

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

Next connect to template0 and perform the pg_proc update. Finally, do

-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';


tsearch2 vulnerability
----------------------

The other error is that the contrib/tsearch2 module misdeclares several
functions as returning type "internal" when they do not have any
"internal" argument.  This breaks the type safety of "internal" by
allowing users to construct SQL commands that invoke other functions
accepting "internal" arguments.  The consequences of this have not been
investigated in detail, but it is certainly at least possible to crash
the backend.

This error affects PostgreSQL 7.4 and later, but only if you have
installed the contrib/tsearch2 module.  The recommended fix is to
change the misdeclared functions so that they accept an "internal"
argument and therefore cannot be called directly from SQL commands.
To do this, execute the following command as a superuser:

    UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
    WHERE oid IN (
        'dex_init(text)'::regprocedure,
        'snb_en_init(text)'::regprocedure,
        'snb_ru_init(text)'::regprocedure,
        'spell_init(text)'::regprocedure,
        'syn_init(text)'::regprocedure
    );

This should report 5 rows updated.  (If it fails with a message
like "function "dex_init(text)" does not exist", then either tsearch2
is not installed in this database, or you already did the update.)

You will need to do this in *each* database in which you have installed
tsearch2, including template1.  You need not worry about template0,
however, since it will certainly not contain tsearch2.

If you frequently install tsearch2 in new databases, you will also
want to modify the tsearch.sql script to declare these functions as
taking type internal in the first place.  (The script fix will be part
of the upcoming releases, so you may be able to wait for those.)


On behalf of the PostgreSQL core committee, I'd like to apologize for
any problems that may arise from these errors.

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005



Re: REMOVE

From
"Nikhil Parva"
Date:
Remove my e-mail id also.


-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org]On Behalf Of
comptech@envirosolution.com
Sent: Tuesday, May 03, 2005 5:51 PM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] REMOVE


REMOVE ME FROM YOUR LIST.......

I am not wanting anymore emails from postgres

E-Mail: comptech@envirosolution.com
Web Site: www.envirosolution.com


-----Original Message-----
From: pgsql-announce-owner@postgresql.org
[mailto:pgsql-announce-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Monday, May 02, 2005 3:07 PM
To: pgsql-announce@postgresql.org
Subject: [ANNOUNCE] IMPORTANT: two new PostgreSQL security problems found

Two serious security errors have been found in PostgreSQL 7.3 and newer
releases.  These errors at least allow an unprivileged database user to
crash the backend process, and may make it possible for an unprivileged
user to gain the privileges of a database superuser.

We are currently preparing new releases that will correct these problems
in freshly initdb'd installations.  However, because these problems are
really incorrect system catalog entries, updating to a new release will
NOT by itself solve the problems in an existing installation.  Instead,
it is necessary for the database administrator to fix the catalog entries
manually, as described below.  We are releasing this advisory to encourage
administrators of PostgreSQL installations to perform these fixes as soon
as possible.


Character conversion vulnerability
----------------------------------

The more severe of the two errors is that the functions that support
client-to-server character set conversion can be called from SQL commands
by unprivileged users, but these functions are not designed to be safe
against malicious choices of argument values.  This problem exists in
PostgreSQL 7.3.* through 8.0.*.  The recommended fix is to disable public
EXECUTE access for these functions.  This does not affect normal usage of
the functions for character set conversion, but it will prevent misuse.

To accomplish this change, execute the following SQL command as a
superuser:

    UPDATE pg_proc SET proacl = '{=}'
    WHERE pronamespace = 11 AND pronargs = 5
          AND proargtypes[2] = 'cstring'::regtype;

In 7.3.* through 8.0.*, this should report having updated 90 rows.
7.4 and later will report a "WARNING: defaulting grantor to user ID 1"
which can be ignored.

The above command must be carried out in *each* database of an
installation, including template1, and ideally including template0 as
well.  If you do not fix the template databases then any subsequently
created databases will contain the same vulnerability.  template1 can
be fixed in the same way as any other database, but fixing template0
requires additional steps. First, from any database issue

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

Next connect to template0 and perform the pg_proc update. Finally, do

-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';


tsearch2 vulnerability
----------------------

The other error is that the contrib/tsearch2 module misdeclares several
functions as returning type "internal" when they do not have any
"internal" argument.  This breaks the type safety of "internal" by
allowing users to construct SQL commands that invoke other functions
accepting "internal" arguments.  The consequences of this have not been
investigated in detail, but it is certainly at least possible to crash
the backend.

This error affects PostgreSQL 7.4 and later, but only if you have
installed the contrib/tsearch2 module.  The recommended fix is to
change the misdeclared functions so that they accept an "internal"
argument and therefore cannot be called directly from SQL commands.
To do this, execute the following command as a superuser:

    UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
    WHERE oid IN (
        'dex_init(text)'::regprocedure,
        'snb_en_init(text)'::regprocedure,
        'snb_ru_init(text)'::regprocedure,
        'spell_init(text)'::regprocedure,
        'syn_init(text)'::regprocedure
    );

This should report 5 rows updated.  (If it fails with a message
like "function "dex_init(text)" does not exist", then either tsearch2
is not installed in this database, or you already did the update.)

You will need to do this in *each* database in which you have installed
tsearch2, including template1.  You need not worry about template0,
however, since it will certainly not contain tsearch2.

If you frequently install tsearch2 in new databases, you will also
want to modify the tsearch.sql script to declare these functions as
taking type internal in the first place.  (The script fix will be part
of the upcoming releases, so you may be able to wait for those.)


On behalf of the PostgreSQL core committee, I'd like to apologize for
any problems that may arise from these errors.

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org



Re: REMOVE

From
Radu-Adrian Popescu
Date:
This is so sad.
How about "please", "thank you", "sorry for being unable to figure out how to
use the mailing list options".


Nikhil Parva wrote:
> Remove my e-mail id also.
>
>
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org
> [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of
> comptech@envirosolution.com
> Sent: Tuesday, May 03, 2005 5:51 PM
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] REMOVE
>
>
> REMOVE ME FROM YOUR LIST.......
>
> I am not wanting anymore emails from postgres
>
> E-Mail: comptech@envirosolution.com
> Web Site: www.envirosolution.com
>


--
Radu-Adrian Popescu

Attachment

Re: REMOVE

From
"Wes Williams"
Date:
And the following is even appended to the bottom of their requests:

TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


AS A NOTE TO OTHERS THAT MAY CONSIDER THIS REQUEST IN THE FUTURE, PLEASE SEE
ABOVE AND THINK BEFORE YOU WRITE!


-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org]On Behalf Of Radu-Adrian
Popescu
Sent: Tuesday, May 03, 2005 8:39 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] REMOVE


This is so sad.
How about "please", "thank you", "sorry for being unable to figure out how
to
use the mailing list options".


Nikhil Parva wrote:
> Remove my e-mail id also.
>
>
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org
> [mailto:pgsql-admin-owner@postgresql.org]On Behalf Of
> comptech@envirosolution.com
> Sent: Tuesday, May 03, 2005 5:51 PM
> To: pgsql-admin@postgresql.org
> Subject: [ADMIN] REMOVE
>
>
> REMOVE ME FROM YOUR LIST.......
>
> I am not wanting anymore emails from postgres
>
> E-Mail: comptech@envirosolution.com
> Web Site: www.envirosolution.com
>


--
Radu-Adrian Popescu


Re: REMOVE

From
Michelle Konzack
Date:
Hello,

how can it be that there are so many stupid peoples ?

I have had never peoblems to (un)subscribe to postgresql, php, debian,
exim, mutt, procmail, fetchmail and many other Mailinglists.

Greetings
Michelle


Am 2005-05-03 15:39:02, schrieb Radu-Adrian Popescu:
> This is so sad.
> How about "please", "thank you", "sorry for being unable to figure out how
> to use the mailing list options".

<snip>


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Attachment

Re: REMOVE

From
"Mohan, Ross"
Date:
LOL!


This reminds me of a long and very satisfying thread on another
db listserv, where some flailing newbie kept writing:


HELP


to the list, thinking he was getting the admin functionality. :)


Finally, someone, in sheer and utter frustration wrote back:


ARE YOU AN IDIOT?


and it became kind of a "list idiom". <chuckling>.



Michelle, it /does/ amaze me that someone can be smart enough
to get into postgres, and join a listserv, dumb enough to not
be able to figure out how to unsubscribe and impolite enough
to do this with no manners whatsoever, all simultaneously.

( That level of mediocrity is usually reserved for people like
the current US president. )



-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Michelle Konzack
Sent: Tuesday, May 03, 2005 8:56 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] REMOVE


Hello,

how can it be that there are so many stupid peoples ?

I have had never peoblems to (un)subscribe to postgresql, php, debian,
exim, mutt, procmail, fetchmail and many other Mailinglists.

Greetings
Michelle


Am 2005-05-03 15:39:02, schrieb Radu-Adrian Popescu:
> This is so sad.
> How about "please", "thank you", "sorry for being unable to figure out

> how
> to use the mailing list options".

<snip>


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Re: REMOVE

From
Stephen Kennedy
Date:
This has happened to me with another mailing list,  I can't remember
which one off-hand.

I tried the unsubscribe functions various times with no success at all
and eventually,  really annoyed,
started replying to ALL messages with something along the lines of "I've
tried to unsubscribe,  it didn't work,  I shall do this until
you solve my problem"
The next day someone wrote suggesting that, as I was not and had not, as
far as she could tell, ever been on that list, maybe I should
look and see whether I was receiving a forward from someone else who had
subscribed.

An ex-workmate had forwarded his mail to our group so we could deal with
work-related stuff,  and so we received all of his
mailing list stuff as well.
This option had not occurred to me.

However,  my solution to the problem did work :)

Stephen.


Mohan, Ross wrote:

>LOL!
>
>
>This reminds me of a long and very satisfying thread on another
>db listserv, where some flailing newbie kept writing:
>
>
>HELP
>
>
>to the list, thinking he was getting the admin functionality. :)
>
>
>Finally, someone, in sheer and utter frustration wrote back:
>
>
>ARE YOU AN IDIOT?
>
>
>and it became kind of a "list idiom". <chuckling>.
>
>
>
>Michelle, it /does/ amaze me that someone can be smart enough
>to get into postgres, and join a listserv, dumb enough to not
>be able to figure out how to unsubscribe and impolite enough
>to do this with no manners whatsoever, all simultaneously.
>
>( That level of mediocrity is usually reserved for people like
>the current US president. )
>
>
>
>-----Original Message-----
>From: pgsql-admin-owner@postgresql.org
>[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Michelle Konzack
>Sent: Tuesday, May 03, 2005 8:56 AM
>To: pgsql-admin@postgresql.org
>Subject: Re: [ADMIN] REMOVE
>
>
>Hello,
>
>how can it be that there are so many stupid peoples ?
>
>I have had never peoblems to (un)subscribe to postgresql, php, debian,
>exim, mutt, procmail, fetchmail and many other Mailinglists.
>
>Greetings
>Michelle
>
>
>Am 2005-05-03 15:39:02, schrieb Radu-Adrian Popescu:
>
>
>>This is so sad.
>>How about "please", "thank you", "sorry for being unable to figure out
>>
>>
>
>
>
>>how
>>to use the mailing list options".
>>
>>
>
><snip>
>
>
>
>

Re: REMOVE

From
Scott Marlowe
Date:
On Tue, 2005-05-03 at 10:57, Mohan, Ross wrote:
> LOL!
>
>
> This reminds me of a long and very satisfying thread on another
> db listserv, where some flailing newbie kept writing:
>
>
> HELP
>
>
> to the list, thinking he was getting the admin functionality. :)
>
>
> Finally, someone, in sheer and utter frustration wrote back:
>
>
> ARE YOU AN IDIOT?
>
>
> and it became kind of a "list idiom". <chuckling>.
>
>
>
> Michelle, it /does/ amaze me that someone can be smart enough
> to get into postgres, and join a listserv, dumb enough to not
> be able to figure out how to unsubscribe and impolite enough
> to do this with no manners whatsoever, all simultaneously.

I always wonder if someone at some company gets stuck taking over an
account for someone who left, and they can't figure out how to get off
the lists that person is on.  It would certainly explain why this seems
to happen sometimes.

> ( That level of mediocrity is usually reserved for people like
> the current US president. )

I think part of the cause there was having to have his spine and part of
his brain removed so Cheney could fit his hand in there like he was a
ventriloquist's dummy.  :) I keed.

Re: REMOVE

From
Alvaro Herrera
Date:
On Tue, May 03, 2005 at 06:17:31PM +0200, Stephen Kennedy wrote:

> An ex-workmate had forwarded his mail to our group so we could deal with
> work-related stuff,  and so we received all of his
> mailing list stuff as well.
> This option had not occurred to me.

That is so annoying :-(  Specially when the receiving account is no
longer available -- the list owner starts getting bounces from an
account he can't unsubscribe, and it's hard to track down who of the
whole list is forwarding to the bogus account.

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"La tristeza es un muro entre dos jardines" (Khalil Gibran)

Re: REMOVE

From
Enrico Weigelt
Date:
* Mohan, Ross <RMohan@arbinet.com> wrote:

<snip>
> This reminds me of a long and very satisfying thread on another
> db listserv, where some flailing newbie kept writing:
>
>
> HELP
>
>
> to the list, thinking he was getting the admin functionality. :)

the majordomo list server has an filter for that, btw.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service
  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
---------------------------------------------------------------------
  Realtime Forex/Stock Exchange trading powered by postgresSQL :))
                                            http://www.fxignal.net/
---------------------------------------------------------------------

Re: REMOVE

From
Christopher Browne
Date:
A long time ago, in a galaxy far, far away, alvherre@dcc.uchile.cl (Alvaro Herrera) wrote:
> On Tue, May 03, 2005 at 06:17:31PM +0200, Stephen Kennedy wrote:
>
>> An ex-workmate had forwarded his mail to our group so we could deal with
>> work-related stuff,  and so we received all of his
>> mailing list stuff as well.
>> This option had not occurred to me.
>
> That is so annoying :-(  Specially when the receiving account is no
> longer available -- the list owner starts getting bounces from an
> account he can't unsubscribe, and it's hard to track down who of the
> whole list is forwarding to the bogus account.

I wouldn't be shocked to see this happen with my @acm.org address at
some point.

I wind up forwarding any messages I want to send via the NNTP gateway,
as it appears that mail that I send with the @acm.org address as email
just plain disappears somewhere between my machine at home and the
mail server at postgresql.org.  Evidently the mismatch between that
and the domain it then comes out of (sympatico.ca) causes someone to
drop it on the floor.

I have correspondingly little confidence that an attempt to send email
to shut off messages would actually work.  So while I can chuckle at
the "idiots," it may not require that for unsubscribe attempts not to
work...
--
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/slony.html
Rules of  the Evil  Overlord #186.  "I will not  devise any  scheme in
which Part A consists of tricking the hero into unwittingly helping me
and Part  B consists of  laughing at him  then leaving him to  his own
devices."  <http://www.eviloverlord.com/>

Re: REMOVE

From
"Mohan, Ross"
Date:
Party poopers!   ;-)

-----Original Message-----
From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Enrico Weigelt

<snip>
> This reminds me of a long and very satisfying thread on another
> db listserv, where some flailing newbie kept writing:
>
>
> HELP
>
>
> to the list, thinking he was getting the admin functionality. :)

the majordomo list server has an filter for that, btw.


cu
--
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

Re: REMOVE

From
Ian FREISLICH
Date:
Enrico Weigelt wrote:
> * Mohan, Ross <RMohan@arbinet.com> wrote:
>
> <snip>
> > This reminds me of a long and very satisfying thread on another
> > db listserv, where some flailing newbie kept writing:
> >
> >
> > HELP
> >
> >
> > to the list, thinking he was getting the admin functionality. :)
>
> the majordomo list server has an filter for that, btw.

Yes, I suggested that they turn that feature on about a year ago.
I was told that they wouldn't because the list administrator (if
there was one) wasn't interested in getting that mail.  Much better
to send it to all the subcribers.

Ian

--
Ian Freislich

Re: REMOVE

From
Grega Bremec
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian FREISLICH wrote:
| Enrico Weigelt wrote:
|
|>* Mohan, Ross <RMohan@arbinet.com> wrote:
|>
|><snip>
|>
|>>This reminds me of a long and very satisfying thread on another
|>>db listserv, where some flailing newbie kept writing:
|>>
|>>
|>>HELP
|>>
|>>
|>>to the list, thinking he was getting the admin functionality. :)
|>
|>the majordomo list server has an filter for that, btw.
|
|
| Yes, I suggested that they turn that feature on about a year ago.
| I was told that they wouldn't because the list administrator (if
| there was one) wasn't interested in getting that mail.  Much better
| to send it to all the subcribers.
|

I think he meant administrivia, where majordomo attempts to filter out
what it suspects might be administrative e-mails directed at the list
instead of the corresponding -request address. The admin need not be
concerned with any of that mail if they do not desire so.

Cheers,
- --
Grega Bremec
gregab at p0f dot net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCf2C9fu4IwuB3+XoRAsurAJwJ0XwaxVipgC4ltyRzv6UBxJyjVACfTraI
QJH12kmwv9UzBZkNsK8CXWs=
=3F06
-----END PGP SIGNATURE-----

Re: REMOVE

From
Ian FREISLICH
Date:
Grega Bremec wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian FREISLICH wrote:
> | Enrico Weigelt wrote:
> |
> |>* Mohan, Ross <RMohan@arbinet.com> wrote:
> |>
> |><snip>
> |>
> |>>This reminds me of a long and very satisfying thread on another
> |>>db listserv, where some flailing newbie kept writing:
> |>>
> |>>
> |>>HELP
> |>>
> |>>
> |>>to the list, thinking he was getting the admin functionality. :)
> |>
> |>the majordomo list server has an filter for that, btw.
> |
> |
> | Yes, I suggested that they turn that feature on about a year ago.
> | I was told that they wouldn't because the list administrator (if
> | there was one) wasn't interested in getting that mail.  Much better
> | to send it to all the subcribers.
> |
>
> I think he meant administrivia, where majordomo attempts to filter out
> what it suspects might be administrative e-mails directed at the list
> instead of the corresponding -request address. The admin need not be
> concerned with any of that mail if they do not desire so.

Yes, administrivia is what I suggested.  The answer I got is what
I posted here now.  Check the archives.  I guess this thread is a
recurring one :)

Ian

--
Ian Freislich