Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal - Mailing list pgsql-bugs
From | Peter Koczan |
---|---|
Subject | Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal |
Date | |
Msg-id | 4544e0330905270925m27bce8c2m60a7a7cec3257161@mail.gmail.com Whole thread Raw |
In response to | Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: BUG #4824: KRB5/GSSAPI authentication fails when user != principal
|
List | pgsql-bugs |
> We should probably at least clarify this release note. =A0Do you want > to make an argument that this is a fundamental breakage and we need > to revert it? =A0If so, what's the argument? Certainly. It seems like with the changes in 8.4, krb5/gssapi auth looks for a valid ticket, and if it finds one, connects without regard for the principal in that ticket. This is a gaping security hole, because it is very nearly the same as trust authentication. I'm me... [koczan@mitchell] ~ $ klist ... Default principal: koczan@CS.WISC.EDU ... I connect as me... [koczan@mitchell] ~ $ /s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 postgres psql (8.4beta2) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help. postgres=3D> select current_role; current_user -------------- koczan (1 row) Now, I connect as someone else... [koczan@mitchell] ~ $ /s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 -U strivia postgres psql (8.4beta2) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help. postgres=3D> select current_role; current_user -------------- strivia (1 row) Now, I connect as superuser... [koczan@mitchell] ~ $ /s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 -U postgres postgres psql (8.4beta2) SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) Type "help" for help. postgres=3D# select current_role; current_user -------------- postgres (1 row) Old clients also exhibit this behavior, so it's also a server-side issue. [koczan@mitchell] ~ $ /s/postgresql-8.3.6/bin/psql -h mitchell -p 49173 -U postgres postgres Welcome to psql 8.3.6 (server 8.4beta2), the PostgreSQL interactive termina= l. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit WARNING: You are connected to a server with major version 8.4, but your psql client is major version 8.3. Some backslash commands, such as \d, might not work properly. SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) postgres=3D# select current_role; current_user -------------- postgres (1 row) And just to show you that there is no trickery, I will attempt to connect without Kerberos tickets. bash-3.2$ whoami koczan bash-3.2$ klist klist: No credentials cache found (ticket cache FILE:/var/adm/krb5/tmp/tkt/krb5cc_0_N26236) ... bash-3.2$ /s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 postgrespsql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information GSSAPI continuation error: Unknown code krb5 195 bash-3.2$ /s/postgresql-8.4-beta/bin/psql -h mitchell -p 49173 -U postgres postgres psql: GSSAPI continuation error: Unspecified GSS failure. Minor code may provide more information GSSAPI continuation error: Unknown code krb5 195 This is trust authentication with one rather inconsequential bit of verification, that's a fundamental breakage. One of the major points of Kerberos is that, for anything that talks Kerberos, you are the principal in that ticket. I understand the desire to change some of that old code, but why is that principal being ignored? Peter
pgsql-bugs by date: