segfault in psql on x86_64
I am running vanilla Fedora Core 1 - test1 for x86_64
running an update system running kernel 2.4.22-1.2166.nptlsmp
The system is a dual opteron pogolinux box with 512M and a IDE RAID 1
from 3ware
I downloaded postgresql-7.4.1-1PGDG.src.rpm
and built it on the system. (rpmbuild --rebuild ...)
and installed the resulting RPM's.
The database starts and stops normally on install
The psql tool ( as well as createuser/vacuum etc all seg fault)
It appears to be faulting on a kerberos call which is odd because I
don't use kerberos for anything.
Here everything plus a gdb backtrace.
[root@bree data]# psql
Segmentation fault
[root@bree data]# gdb psql
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/psql
[Thread debugging using libthread_db enabled]
[New Thread 182894073344 (LWP 5363)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894073344 (LWP 5363)]
0x0000003de59010e0 in ?? () from /lib64/tls/libm.so.6
(gdb) bt
#0 0x0000003de59010e0 in ?? () from /lib64/tls/libm.so.6
#1 0x0000003de6e16c61 in krb5int_initialize_library () from
/usr/lib64/libkrb5.so.3
#2 0x0000003de6e413fb in krb5_init_secure_context () from
/usr/lib64/libkrb5.so.3
#3 0x0000003e2d40844e in pg_krb5_init (PQerrormsg=0x7fbfffda50 "
�\177") at fe-auth.c:291
#4 0x0000003e2d4085a9 in pg_krb5_authname (PQerrormsg=0x3de6f6bc80
"4�") at fe-auth.c:348
#5 0x0000003e2d408ce1 in fe_getauthname (PQerrormsg=0x7fbfffda50 "
�\177") at fe-auth.c:731
#6 0x0000003e2d40af56 in conninfo_parse (conninfo=0x5320c0 "uA->",
errorMessage=0x529db0) at fe-connect.c:2720
#7 0x0000003e2d408db8 in connectOptions1 (conn=0x529a20,
conninfo=0x3de6f6bc80 "4�") at fe-connect.c:328
#8 0x0000003e2d4091e3 in PQsetdbLogin (pghost=0x0, pgport=0x0,
pgoptions=0x0, pgtty=0x0, dbName=0x0, login=0x0, pwd=0x0)
at fe-connect.c:541
#9 0x000000000040a1db in main (argc=1, argv=0x7fbfffe058) at
startup.c:183
(gdb)
--
Orion Henry <orion@trustcommerce.com>
Orion Henry <orion@trustcommerce.com> writes:
It appears to be faulting on a kerberos call which is odd because I
don't use kerberos for anything.
I was a bit surprised to realize that if you compile Kerberos support at
all, libpq will try to get a user name from Kerberos in preference to
using getpwuid(). This strikes me as odd and surprising behavior.
There's certainly no security reason for it, since we are only getting
a default user name that can be trivially overridden.
Does anyone see a reason why we shouldn't trust getpwuid to supply the
default username in all cases? I'm thinking of ripping out
fe_setauthsvc/fe_getauthsvc as well ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
Orion Henry <orion@trustcommerce.com> writes:
It appears to be faulting on a kerberos call which is odd because I
don't use kerberos for anything.I was a bit surprised to realize that if you compile Kerberos support at
all, libpq will try to get a user name from Kerberos in preference to
using getpwuid(). This strikes me as odd and surprising behavior.
There's certainly no security reason for it, since we are only getting
a default user name that can be trivially overridden.
Harumph. I reported this about a year ago:
http://archives.postgresql.org/pgsql-general/2002-12/msg00740.php
I'm not sure it can be fixed by just not setting the default username though.
In fact I think there's something a little backwards about deciding on a
default username in advance and then trying various authentication methods.
In my case I have a kerberos principal gsstark@ATHENA.MIT.EDU and a local
username of "stark".
It seems like it should try to do the kerberos authentication as username
"gsstark" (or even "gsstark@ATHENA.MIT.EDU" since the realm is significant).
And if that fails, then it should try to log in as "stark" using unix userid
authentication.
The only fear I have with that direction is that it makes things a bit
unpredictable. I could see it being weird having scripts randomly fail because
they logged in as the wrong user if the tickets happened to have expired or
the network goes down.
--
greg
Greg Stark <gsstark@mit.edu> writes:
In fact I think there's something a little backwards about deciding on a
default username in advance and then trying various authentication methods.
Perhaps, but we're stuck with that without a massive (and non backwards
compatible) redesign of the connection protocol. libpq has to send a
connection-request packet that includes the username before it knows
which auth method will be selected. There are people around here who
consider it a feature that pg_hba.conf can base the decision which auth
method to use on the supplied username...
In my case I have a kerberos principal gsstark@ATHENA.MIT.EDU and a local
username of "stark".
AFAICS libpq doesn't have any very principled way to choose which of
those to use as default username. But I'd prefer to see it make the
same choice whether it's compiled with kerberos support or not. The
present behavior doesn't seem to me to satisfy the principle of least
astonishment.
In your situation, if you wanted to log in using kerberos authentication
then you'd probably end up setting PGUSER=gsstark to get the right thing
to happen.
regards, tom lane