Re: PostgreSQL 7.3.3 with pgcrypto on FreeBSD 5.1

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Alex Rodin <alx(at)sm(dot)ukrtel(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: PostgreSQL 7.3.3 with pgcrypto on FreeBSD 5.1
Date: 2003-07-22 20:39:28
Message-ID: 20030722203928.GV64860@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> ----------------------------------------------------------------------
>
> testdb=# SELECT crypt('lalalal',gen_salt('md5'));
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> <pglog>
>
> LOG: ReadRecord: record with zero length at 0/18BDEA8
> LOG: redo is not required
> LOG: database system is ready
> LOG: server process (pid 21460) was terminated by signal 11
> LOG: terminating any other active server processes
> LOG: all server processes terminated; reinitializing shared memory and semaphores
> LOG: database system was interrupted at 2003-07-21 11:44:47 EEST
> LOG: checkpoint record is at 0/18BDEA8
> LOG: redo record is at 0/18BDEA8; undo record is at 0/0; shutdown TRUE
> LOG: next transaction id: 996; next oid: 98896
> LOG: database system was not properly shut down; automatic recovery in progress
> FATAL: The database system is starting up
> </pglog>

FWIW, I can confirm this, but I don't think it's a FreeBSD specific
problem given that the backend dies inside of an OpenSSL routine.

#0 0x2864ae9c in EVP_DigestUpdate () from /usr/lib/libcrypto.so.3
#1 0x28576a90 in px_find_cipher () from /usr/local/lib/postgresql/pgcrypto.so
#2 0x2857c584 in px_crypt_md5 () from /usr/local/lib/postgresql/pgcrypto.so
#3 0x2857efa4 in px_gen_salt () from /usr/local/lib/postgresql/pgcrypto.so
#4 0x2857ee1f in px_crypt () from /usr/local/lib/postgresql/pgcrypto.so
#5 0x2857d2be in pg_crypt () from /usr/local/lib/postgresql/pgcrypto.so
#6 0x0811acb6 in ExecMakeFunctionResult ()
#7 0x0811b7db in ExecEvalExpr ()
#8 0x0811e794 in ExecProject ()
#9 0x0811cb7a in ExecProject ()
#10 0x081282a5 in ExecResult ()
#11 0x0811a0e5 in ExecProcNode ()
#12 0x0811952c in ExecEndPlan ()
#13 0x081188b8 in ExecutorRun ()
#14 0x0819b703 in PortalRun ()
#15 0x0819b53e in PortalRun ()
#16 0x08199b21 in authdie ()
#17 0x081982fd in PostgresMain ()
#18 0x0816de64 in PostmasterMain ()
#19 0x0816d628 in PostmasterMain ()
#20 0x0816bcc6 in PostmasterMain ()
#21 0x0816b5c7 in PostmasterMain ()
#22 0x0813588b in main ()
#23 0x0806c802 in _start ()

Both crypt() and gen_salt() work independently of each other:

test=# SELECT gen_salt('md5');
gen_salt
-------------
$1$nouzuI/B
(1 row)

test=# SELECT crypt('foo','ba');
crypt
---------------
ba4TuD1iozTxw
(1 row)

:-/ crypt() does die with the salt, '$1$' Not sure why either...

That said, the right work around is to _not_ use gen_salt('md5') when
passing data in to crypt(), instead, use gen_salt('des'). The readme
says its not recommended, but in the same breath, it should recommend
that gen_salt('des') is as weak as crypt() and gen_salt('des')
produces the correct salt for use with crypt().

What's interesting, however, is that I can no longer ctrl+c to get out
of psql after the backend dies. To kill psql, I have to suspend it,
then kill.

test=# SELECT crypt('lalal',gen_salt('md5'));
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL
!>
!>
!>
!>
!>
!>
!>
[1] + 15252 Suspended psql test pgsql
1:08pm sean(at)localhost:databases/postgresql-devel > kill %1
1:08pm sean(at)localhost:databases/postgresql-devel >
[1] Terminated psql test pgsql

-sc

--
Sean Chittenden

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Misha Gale 2003-07-23 08:56:40 Re: HELP! BUG? pg_dump mucks up grant/revoke
Previous Message Tom Lane 2003-07-22 19:35:27 Re: [GENERAL] INSTEAD rule bug?